Data Network Resource
       Earn on the Web

24. NT Directory Services

Multiple Account Administration is not necessary with the concept of 'one user, one account' where a user can access resources across domains using Pass-Through Authentication and Universal Resource Access.

The Directory Database can be partitioned throughout the network.

Directory Service Manager for NetWare (DSMN) is used to provide a simple logon process for NetWare 2.x/3.x users by synchronising accounts across all the NetWare servers, accounts can be merged, account changes made on the NT server are copied back to the NetWare servers and specific user and group accounts can be managed centrally.

NTDS is used by Backoffice applications to authenticate users and their permissions in one go for both the network and the applications.

Implementing NTDS requires that the Domain model is chosen for the network, that Trust relationships are setup correctly and the best location of servers is decided.

For users in Domain A to be able to access resources in Domain B a Trust relationship needs to be set up. Domain B becomes the Trusting Domain and Domain A becomes the Trusted Domain. Accounts set up in Domain A can access Domain B as if the accounts exist in that domain. Diagrammatically the arrow points towards the Trusted domain where the user accounts are. A Two-Way Trust is where both Domains trust each other and this is represented by two arrows pointing opposite ways. Where a user's account reside is important when setting up trusts. The trick is to minimise the number of trusts that are required.

By default NT uses Global Accounts which can cross trusts. There are also available Local Accounts that can only be used in an Untrusted Domain.

As always Users are placed in Global groups and Global groups are placed into Local Groups. The Global groups are defined in the trusted domain and the Local groups exist everywhere to allow permissions to be assigned to resources locally. Only create a local group if one does not exist that can do the job.

The NetLogon service is required to validate user logons, synchronise BDCs with PDCs and to implement Pass-Through Authentication which identifies a user using the name format DomainName\Username (this only works with NT clients).

The domain's SID must be unique to set up a trust, in addition, the PDC in each domain must not have any sessions between them, the trust is set up between PDCs by the administrator using the system account. Trusts are set up in User manager for Domains in the Policies menu. In the Trust Relationships box you type in the trusting and the trusted domains (in that order, otherwise it can take up to 15 minutes for the relationship to start). A two-way trust is implemented in the same manner so that both domains are listed in each box. A one off password can be assigned, and this must be the same at each end.

Permissions between two domains cannot be passed through to a third domain i.e. trusts are non-transitive. A broken trust might occur due to a faulty network connection, a domain has been renamed or there is a faulty Netlogon service.

In the Single Domain Model no trusts are required, all users and global groups are in one domain. This is ok provided that there are fewer than 40,000 in the user base.

In the Single Master Domain Model there are at least two domains with all the account information kept in the Master Domain. Ideal for an organisation that has different departments wanting their own resource management. A resource administrator would place global groups into local groups in the trusting domains (where the resources are).

In the Multiple Master Domain Model accounts are distributed among a number of Master Domains. Multiple administrative units can control their own accounts. Two-way trusts link the master domains so all accounts can have access to all domains. The number of trusts is found using the formula M*(M-1)+(R*M) where M is the number of master domains and R is the number of Resource domains. If a local group needs to contain global groups from two or more master domains then a global group must be created in each master domain.

The Complete Trust Domain Model has two-way trusts between all domains and allows you to have the management of both accounts and resources distributed among different departments. The number of trusts required is given by the formula n*(n-1) where n is the number of domains.

The 40,000 maximum accounts limit includes user accounts, group accounts and computer accounts and these are stored as objects in the Security Accounts Manager (SAM). A User Account takes up 1 Kb, a Computer Account takes up 0.5 Kb, a Global group account takes up 512 bytes for the group and 12 bytes per user and the Local Group account takes up 512 bytes for the account and 36 bytes per account. The SAM file should not take up more than 40 Mb.

A 486DX/66 CPU with 32Mb RAM could support up to 7,500 users in a SAM file of 10Mb; whereas a Pentium CPU with 128Mb RAM could support up to 40,000 users in a SAM file of 40Mb. The number of Master Domains is determined by the number of users and the organisational structure e.g. Human Resources could have it's own domain spread over a number of countries. There ought to be one BDC for every 2000 users.

The controllers that do the most work should be the most powerful. For instance, a BDC that processes a large number of validation requests in a resource domain should be more highly specified than a PDC that just processes all user accounts.

Master domain BDCs are best placed locally in a resource domain since when a user wishes to access a resource domain, the PDC/BDC in the resource domain contacts the master domain to validate the user. It is far better to do this locally than over the WAN.

Having a BDC either side of the WAN link also means that the bandwidth is used for the synchronisation of the Directory Database controlled by the NetLogon Service. Full Synchronisation occurs when a BDC is brought online, Partial Synchronisation occurs when the PDC just sends the changes. The default size for the change log is 64Kb and each entry takes up 32 bytes (therefore allowing 2000 changes). If a BDC sees that the last change has been overwritten then it will initiate a Full Synchronisation. To change the log size add the value as a REG_DWORD in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\ChangeLogSize

A PDC sends a change message only to the relevant BDCs and then in small groups at a time in each pulse. This stops too much bandwidth being used at once. The ReplicationGoverner parameter located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters decides the frequency of the calls and the size of of data transferred each time. NetLogon 'sleeps' in between calls. Again the parameter type is REG_DWORD and the default value is 100, which means that 100% of the data is transferred each call (128Kb buffer) and that synchronisation can occur for 100% of the time i.e. NetLogon never sleeps. A value of 50 gives a 64Kb buffer and 50% of the time (this should never be less than 25). The trick is to make sure that a wrap does not occur on the change log, reducing the number increases the amount of time it takes for data to be replicated. Stopping and starting the NetLogon service at different times can be done using a batch file in conjunction with the At command. When NetLogon is paused it carries on the synchronisation process but not the logon or pass-through authentication.

Valid HTML 4.01 Transitional

Earn on the Web    

All rights reserved. All trademarks, logos, and copyrights are property of their respective owners.