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.
|
