Introduction to Active Directory
Hierarchical directory service that stores information about objects, which
can be resources, services, and users. An object is uniquely identified by its
name and has a set of attributes. Attributes are defined by a schema, which
also determines the kind of objects that can be stored in the AD.
schema class objects
schema objects = metadata
At the top of an AD directory sits a forest, which includes trees. A tree
contains one or more domains and domain trees. Trees and domains are linked
in a transitive trust hierarchy. A domain maps to a single DNS domain. AD is
TCP/IP-based instead of NetBIOS, and requires a DNS server that supports the
SRV resource records.
Objects held into a domain can be grouped into Organizational Units (OU);
OU can contain nested OUs. Actually, it's best to use as few domains as possible,
and rely on OUs to organize objects instead. Group policies (Group Policy Objects,
or GPOs) are commonly applied to OUs.
While OUs are logical groupings, sites are physical groupings, are defined
by one more IP subnets, and can be distinguished by connection speed (WAN and
VPN are low-speed locations, LAN is high-speed.) Sites can contain domains,
and domains can contain sites. Sites are used to organize AD replication between
servers, with intrasite replication being frequent and automatic, while intersite
replication being configurable to reduce cost. Servers without AD are called
Common models to organize a company's directory is by business, by geographical
location, or by IT roles.
Every object has a Distinguished name (DN), eg. CN=HPLaser3,OU=Marketing,DC=foo,DC=org
where CN is common name and DC is domain object class, DNs can have many more
than four parts.
The object can also have a Canonical name, essentially the DN in reverse,
without identifiers, and using slashes: foo.org/Marketing/HPLaser3. To identify
the object within its container the Relative distinguished name (RDN) is used:
CN=HPLaser3. Each object also has a Globally unique identifier (GUID) a unique
and unchanging 128-bit string which is used by AD for search and replication.
Certain objects also have a User principal name (UPN), an objectname@domain
AD is split into three different stores or partitions, a.k.a. 'naming contexts':
- The 'Schema' partition contains the definition of object classes and
attributes within the Forest
- The 'Configuration' partition, contains information on the structure
of the forest
- The domain partition holds all objects created in that domain. The first
two partitions replicate to all domain controllers in the Forest. The Domain
partition replicates only to Domain Controllers within its domain. A Partial
Attribute Set (PAS) of all objects also replicates to the global catalog.
NTDS.DIT (the AD database, a.k.a. "directory store") has two main
tables in Windows 2000: the data table and the link table. In Windows 2003 a
third main table was added for security descriptor single instancing.
AD information is held on one or more domain controllers (DCs). For backward
compatibility, an AD server can be set up as a flexible single master operation
(FSMO) to simulate a PDC. Each DC holds a single domain partition and a read-and-write
copy of the AD, changes on one computer being synchronized (converged) between
all the DC computers by multi-master replication.
In addition to providing legacy support for older clients and NT4 servers,
a DC designated as FSMO plays roles like Schema Master, Domain Naming Master
(to create and delete domains in the forest), domain master browser, etc.
To minimize replication traffic, a domain in a multi-domain forest only contains
objects that belong in that domain, and those objects only live in the DCs of
that domain. Global catalog (GC) servers, which are DCs, provide a global
listing of all objects in the forest, but, to further minimize traffic, only
a subset of attributes are replicated among GC servers.
Replication is usually done using RPCs (Remote Procedure Calls), although
some changes can be replicated using SMTP.
To allow users in one domain to access resources in another, AD uses trust.
Trust is automatically produced when domains are created. The forest sets the
default boundaries of trust, not the domain, and implicit trust is automatic.
Simply speaking, AD uses trust to allow users in one domain to have access to
resources in another domain. The AD trust has a two way trust with its parent.
The root of every tree has a two way trust with the Forest Root domain. As a
result, every domain in the forest, either explicitly or implicitly, trusts
every other domain in the forest. These default trusts cannot be deleted.
What was wrong with NT4?
- The structure of records in the SAM database could not be changed or expanded to fit needs; In AD, the schema upon which the database is built can be customized
- Limited capacity in the number of objects that could fit in the SAM
- Only one host in each NT domain, the PDC, had write access to the database; In an AD-based NT domain, there is no such thing as PDCs and BDCs. All DCs have read-write access to the database
- The SAM could only be accessed through a proprietary protocol; AD uses LDAP
- Server discovery was done over and over again; In AD, resources are published in the directory for all to see
- NT domains being non-hierarchized, it was difficult for a company to expand by having sub-domains just like DNS. Setting up master and resource domains was no easy task; AD-base NT domains make this very easy
- Poor granularity when it comes to limiting administrative rights: The best you could do, is create different global groups, assign different administrators, and change who belonged to the local Admins groups on each and every NT host; Since AD offers sub-domains, you can just create Organizational Units (OU) to delegate admin control to sub-domains to local MIS personnel instead of grating them admin rights on the entire domain
- Lack of transitive trusts, which required setting up one- or two-way trust relationships with each remote domain to which you wanted to communicate; AD offers transitive trusts (If DOMAIN_A trusts DOMAIN_B, and DOMAIN_B trusts DOMAIN_C, then DOMAIN_A trusts DOMAIN_C with no further ado.)
Installing a brand new Win2K host
Just like NT4, Win2K servers can be either stand-alone ("member servers") or DCs. When installing a Win2K, you will be asked whether it will be part of a domain, or be a stand-alone host. After rebooting, you have to tell W2K if this server in the only server on your network (ie. first DC in the domain), or if one or more servers are already running (ie. this new server will be a new DC in an existing domain).
Next, you have to set up Active Directory through the AD Wizard: Will this new server be the first DC in a new forest (ie. creating a new forest, and a first domain tree), be the first DC in a new domain in an existing forest, be the first DC in a child domain in an existing domain, or simply be an additional DC in an existing domain.
Migrating an NT4 domain to AD
Upgrade the PDC in the first master domain to W2K. From then on, this DC operates in mixed-mode, ie. it hosts the AD but acts like regular NT4 DCs to legacy NT4 devices.
Once the PDC has been upgraded to W2K, all W2K workstations can take advantage of some AD features. Each new domain whose PDC is upgraded to W2K becomes part of the forest that was created when the PDC in the first domain was upgraded.
What is AD, and how does it work?
AD's main components are its logical structure (OUs, domains, trees, and forests) and physical structure (sites, DCs). Unlike NT4 domains, Win2K-based domains use a multimaster replication model, ie. any DC has write-access to AD.
In AD-speak, a downlevel DC is an NT4 server, and a downlevel domain is one running an NT4 or earlier PDC. A downlevel client is any host not running Win2K. Downlevel computer or domain names are NetBIOS names.
Simply the directory's internal structure. It defines the relationships betweens classes of objects, and the attributes each class of object is allowed to have (eg. a object of class Computer can have attributes like Name, IP address, etc.) Just like in Object-oriented languages, classes inherit attributes from higher-level classes. All the domains in a forest share a common schema. It is not possible to merge multiple forests or schemas. When two companies merge (ie. each has its own AD forest of domains), the best thing to do is use third-party tools to move objects from one forest into the other. A less ideal solution is to use non-transitive trust relationships to link the two forests.
NT4 used LMHOSTS file, WINS server, and broadcasts to find other hosts. Windows 2000 rely on the DNS to locate resources, eg. DCs. To avoid clients from being authenticated by DCs in remote sites, make sure that DCs for the ad hoc domain are available in each location.
Add DCs in a forest have up-to-date information through the Update Sequence Number (USN) so only changes are replicated instead of the entire DIT. Three replication naming contexts are used to replicate domain and AD information between DCs: Domain naming context (DIT changes to DCs withing one domain), schema naming context (schema information to all DCs within a forest), and configuration naming context (configuration information such as replication topology to all DCs in a forest.)
Distributed File System (DFS)
Clients can be redirected to shared folders at their own site, if available.
Directory Information Tree (DIT)
A replacement for the SAM. Based on MS Jet, the same database engine used by Exchange. The database is \%systemroot%\ntds\ntds.dit. Its contents is replicated on all the DCs in a domain.
NT4 only had local and global groups. W2K offers global and domain local groups, as well universal groups. Universal groups are available only in W2K DCs running in native mode. Universal groups can contain global groups and other universal groups from any domain in the forest.
A forest contains either a single domain tree or a set of domain trees that have different namespaces (eg. microsoft.com, oracle.com, etc.) but trust each other at the root through Kerberos. When you install a new DC, you are asked whether it will be a DC in a new forest, or it will be an additional DC in an existing forest. All domains in a tree share a common schema.
All domain controllers in a domain replicate information to each other. For backward compatibility, AD domains can still be reached through the familiar 15-character NetBIOS name, but W2K domains actually live in the DNS, eg. mydomain.com. A domain name cannot be changed afterwards without a lot of work. Likewise, a DC cannot have its name changed; a solution is to have it demoted to non-DC status (ie. member server) using DCPROMO.EXE, and change its name.
A domain tree lives in a forest, and contains a domain and sub-domains that trust one another and belong to a continuous namespace.
Organization Units (OU)
A container object used to delegate administrative duties to a sub-group of users in a Win2K domain. While the domain was the unit of delegation in NT4, it is the OU in Win2K. With OUs, you no longer need resource domains, as the objects it contained can be moved to an OU after being upgraded.
A set of IP subnets that are connected with high-speed links, ie. a LAN. Grouping servers in a site offers the benefit of lowering WAN traffic by keeping authentication requests and DC replications in the local network (intra-site replication), something which was difficult to do with NT4 since it didn't have any idea about where DCs where physically located. Site-aware clients use the DNS to find DCs that live in their subnet. Use the AD Sites & Services applet to define sites manually.
Mixed and native modes
A W2K domain running in mixed mode can contain W2K DCs and NT4 BDCs. A W2K DC running in native mode only works with other W2K DCs.
Windows 2000 Active Directory domains can run in one of two modes: mixed
and native. Mixed mode provides support for Windows NT backup domain controllers
(BDCs) while preventing the use of certain NT-incompatible Active Directory
features, such as universal security groups. Windows Server 2003 takes the concept
of modes a step further, and it renames them functional levels.
Similar to Windows 2000 Active Directory modes, functional levels enable
Active Directory to remain compatible with older versions of Windows while preventing
the use of certain features that would compromise backward-compatibility. Every
Windows Server 2003 Active Directory domain starts in the Windows 2000 mixed
functional level, which is identical in functionality to the Windows 2000 mixed
mode. Domain functional levels include
- Windows 2000 mixed— In this mode, you can have Windows NT, Windows Server
2003, and Windows 2000 domain controllers.
- Windows 2000 native— In this mode, you can have only Windows 2000 and
Windows Server 2003 domain controllers.
- Windows Server 2003— In this mode, you can have only Windows 2003 domain
Because Windows Server 2003 also introduces new forest-wide functionality
to Active Directory, forests have their own functional levels, as follows:
- Windows 2000— This mode supports a forest containing Windows 2000 or
Windows Server 2003 domains running at any domain functional level.
- Windows Server 2003— This mode supports only Windows Server 2003 domains
running in the Windows Server 2003 domain functional level.
Win2K uses Kerberos as its default authentication protocol, and this means that trusts are transitive. This means that you do not need to set up a mesh of relationships to have sub-domains trust each other. Thus, a domain tree is a set of sub-domains that trust each other and that belong to a continuous namespace (eg. acme.com, subdomain.acme.com, and rd.subdomain.com).
Global Catalog servers
A Global Catalog is an index of objects in an AD forest, but contains only a subset of each object's attributes. Its role is to minimize the time it takes to locate an object that lives in another domain in the forest. In Exchange 2000, the GC replaces the Global Address List.
At least one GC server is needed in each network for clients to authenticate to the AD domains. While most domain information are replicated on all the DCs that belong to a domain, AD replicates the GC to all the DCs that belong to the forest.
The first DC in a domain is automatically designated as a Global Catalog server, but any DC can act as a GC server. Each GC server has write-access to three directory partitions: domain directory partition (includes users, computers, etc.), schema directory partition (schema containter, which includes class and attibutes), and the configuration directory partition (configuration objects for the entire forest, eg. sites, services, etc.) In addition, each GC server has read-only access to some of the attributes contained in other directory partitions. Use the AD Sites & Services to manually specify other DCs to be GC servers.
When adding a new domain to a forest, information about this new domain is added to the GC server in the configuration directory partition, and those data are replicated onto all other GC servers in the forest. This is precisely because each GC server contains data about all the domains that live in a forest, that a developed can obtain information about any object in any domain. If a GC is prompted for a query on the LDAP port (389) and cannot find the requested information in its domain in the three directory partition, the request is referred to a GC in a different domain that might have the answer through an LDAP referral. On the other hand, if a GC server is prompted on port 3268 (default for GC), the search will include all directory partitions in the forest and will be performed by a single GC instead of prompting a different GC in each domain successively.
Making every DC a GC server uses a lot of networks bandwidth. Each location should have a DC and GC and only send queries through the WAN if local servers are kaput. Theoratically, GC servers are not needed in a single-domain forest, but some applications are hard-coded into querying GC servers no matter what.
Administrative rights can be delegated to sub-domains, ie. Organization Units (OUs). In Win2K, the OU is the unit of delegation, while it was the domain in NT4.
How do OUs fit in W2K domains?
Do NT4 domains just appear as child-less domains, while W2K domains can have sub-domains?
How to have NT4 domains show up in NetHood?
How to have NT4 users and W2K users access each other's resources without creating additional user accounts?
What's the difference between a OU and a sub-domain?
What's the difference between global, domain local, universal groups, and distribution groups?
Are all W2K servers DCs, or can application server be just member servers?
Can an NT4 and NT4 DCs