|
|
|
|
|
|
|
|
Installing a Windows 2000 domain creates a
parent/child trust |
|
Adds a new domain to existing domain tree |
|
Every domain has at most one parent domain |
|
Multiple child domains |
|
Cross-links for frequent resource use |
|
Between domains in the tree |
|
Defining explicit trust to other domains outside
directory tree |
|
External domain management not part of the tree
of trust |
|
Business partnerships requires shared access to
resources |
|
|
|
|
|
Trust relationship to domains outside the tree
are non-transitive |
|
Users can access resources only in the domain to
which they are directly connected |
|
|
|
|
|
|
|
|
|
Certain operations require a master role holder |
|
FSMO roles: |
|
One master role holder per forest |
|
Schema Master - Schema Management |
|
Domain Naming Master - Domain Tree Management |
|
One master role holder per Domain |
|
PDC Emulator – PDC for Windows NT 4.0 BDCs,
Password conflicts, Domain Master Browser |
|
Infrastructure FSMO – Maintains changes for
cross-domain object references |
|
Rid Master - RID Pool Allocation |
|
First DC in forest will maintain all five FSMO
roles |
|
Ntdsutil can be used to transfer or seize a role |
|
|
|
|
|
|
There are two main administration goals: |
|
Setting ACLs to control visibility and access to
objects in the directory |
|
Delegating administration |
|
The Organizational Unit provides the flexibility
for accomplishing these goals |
|
|
|
|
|
Used to structure Active Directory based on: |
|
A company’s organizational structure |
|
A company’s administrative model |
|
Administrative Control assigned to an OU;
Includes control of the objects within the OU |
|
|
|
|
|
Organizational Units can contain: |
|
Users, groups, printers, computers |
|
Administrators |
|
Group policy |
|
Subordinate (nested) OUs |
|
Very flexible - easy to create, delete, change |
|
|
|
|
Department-based OUs |
|
Project-based OUs |
|
Business function-based OUs |
|
Administration-based OUs |
|
Object-based OUs |
|
Geographic |
|
|
|
|
OU security provides the mechanism for
controlling object visibility and delegating administration |
|
|
|
|
The creation of objects can be delegated at OU
level |
|
|
|
|
|
Windows 2000 provides a wizard to help delegate
control on tasks |
|
Can use predefined tasks included with the
wizard |
|
Create custom tasks from list of all ACLs
available |
|
|
|
|
|
|
Without controlling individual ACLs on objects,
OUs are the only way of delegating administration |
|
Your OU model must reflect your required
administrative model |
|
What do you want? |
|
Centralized |
|
Decentralized |
|
|
|
|
|
|
|
|
Multi-master replication |
|
All domain controllers (DC) are peers |
|
Changes to one DC replicated to all DCs |
|
RID space partitioned out to different DCs |
|
Simultaneous changes can be made on different
DCs |
|
Sites allow scheduled replication |
|
|
|
|
|
|
Naming Contexts are the boundaries for
replication |
|
Existing naming contexts (NCs): |
|
Configuration (enterprise-wide context) |
|
Site definition, service configuration,
replication topology |
|
Schema (enterprise-wide context) |
|
Classes, attribute mapping to objects |
|
Domains in enterprise (domain-wide context) |
|
Enterprise-wide context for partial replication
to Global Catalogs |
|
Users, computers, other domain objects |
|
|
|
|
|
64-bit DWORD |
|
DC local meaning |
|
Assigned to new object update transaction |
|
If transaction is aborted, the USN is not
assigned to any object |
|
Each object carries two USNs |
|
usnCreated |
|
usnChanged |
|
Each property carries two USNs |
|
Indexed property in the database |
|
Independent from system time |
|
|
|
|
|
Conflict resolution |
|
Resolution: higher version number -> higher
timestamp -> higher GUID of originating write DSA |
|
|
|
|
|
|
|
|
|
Table on each DC |
|
Replication partners |
|
Highest known USN |
|
Used to detect recent changes on replication
partners |
|
|
|
|
|
DC4’s high watermark vector |
|
Assuming that DC1 and DC3 are its replication
partners |
|
|
|
|
|
Up-to-dateness related to a specific naming
context |
|
List of pairs: |
|
Originating-DC-GUID (database GUID) |
|
Highest-originating-USN |
|
Only those DCs are added from which originating
updates have been received (even through replication) |
|
|
|
|
|
|
|
DC4’s up-to-dateness vector |
|
Assuming that only DC1 and DC2 (and maybe DC4)
performed originating write operations |
|
|
|
|
|
Naming context for which changes are requested |
|
Maximum number of object update entries
requested |
|
Maximum number of values requested |
|
High-USN-changed value of naming context of
replication partner |
|
Complete up-to-dateness vector |
|
Used for propagation dampening |
|
|
|
|
|
Step 1: User added to DC2 |
|
No changes for DC4 |
|
|
|
|
|
Step 2: User replicated to DC1 |
|
No changes for DCS4 |
|
Note: Write was originated on DC2! |
|
|
|
|
|
Step 3: DC4 initiates replication with DC1 |
|
Sends NC, highest known USN DC1 for this NC, #
objects, # values, up-to-dateness vector |
|
|
|
|
|
Step 4: DC1 replicates new user to DC4 |
|
Sends data, last-object-changed USN, state data |
|
DC4 uses this data to improve it’s
up-to-dateness |
|
|
|
|
|
Step 5: DC2 replicates new user to DC3 |
|
No changes for DC4 |
|
|
|
|
|
Step 6: DC4 initiates replication with DC3 |
|
Sends NC, highest known USN DC3 for this NC, #
objects, # values, up-to-dateness vector |
|
|
|
|
|
Step 7: DC3 replication reply |
|
Determines that DC4 already is up-to-date |
|
Sends last-object-changed USN, up-to-dateness
vector, but no data! |
|
|
|
|
|
|
DC GUID is used to construct the ring |
|
New installed DCs add themselves to the ring,
and replicate the new configuration information |
|
Existing DCs add and/or remove connection
objects |
|
|
|
|
|
For domain naming context: RPC only |
|
For GC, configuration, and schema: RPC and SMTP
supported |
|
SMTP replication uses ISM (inter-site messaging)
service |
|
Asynchronous replication protocol |
|
No notification |
|
Changes are requested for each Naming Context |
|
Compression (about 10–15% of data volume) |
|
Inter-Site Topology Generator |
|
|
|
|
|
|
Always, if slow links are involved |
|
Slow link = < 10 Mbps |
|
Place DCs into sites |
|
Rules of thumb |
|
Deploy GCs on a site level |
|
Deploy DNS servers on a site level |
|
Connect sites with site links according to
network characteristics |
|
|
|
|
|
|
Sites indicate areas of high bandwidth |
|
Consist of one or more subnets |
|
Intra-Site replication is RPC based |
|
Notification based |
|
Inter site replication may be |
|
RPC (TCP/IP) - used for all NCs |
|
Inter-Site Messaging Services(ISM)\SMTP |
|
Used for Configuration, Schema NC only |
|
Sites may be configured by administrator |
|
|
|
|
|
|
TCP/IP (default) |
|
SMTP (Inter-Site only) |
|
May be assigned by administrator, but limited by
naming context |
|
|
|
|
|
|
|
|
Bridgehead servers are replication “gateways” to
remote sites |
|
Bridgehead servers do not store and forward NCs
which they do not host |
|
This may result in multiple bridgehead servers
in a given site |
|
|
|
|
|
|
A Site Link Bridge (SLB) contains two or more
site links |
|
Remember: Site links are networks |
|
Bridges connect site links |
|
They work like bridges/routers between networks |
|
These site links should have at least one site
in common |
|
Cost for transport is used to make routing
decisions; uses cost to evaluate the "least cost path" |
|
Knowledge Consistency Checker (KCC) creates
minimum cost routes which can span multiple site links |
|
Create multiple SLBs for non-routed segments
(VPNs and so on) |
|
Default: All links in one SLB |
|
|
|
|
|
|
|
|