Active Directory (codename Cascade) is an implementation of LDAP directory services by Microsoft for use in Windows environments. Active Directory was previewed in 1996, released first with Windows 2000, and saw some revision to extend functionality and improve administration in Windows Server 2003.
Unlike earlier versions of Windows which used NetBIOS to communicate, Active Directory is fully integrated with DNS and TCP/IP - indeed DNS is required. To be fully functional, the DNS server must support SRV resource records or service records. Windows 2000 workstations can still function using WINS to locate the servers, but Active Directory will not function properly without a DNS server that supports SRV.
Active Directory allows administrators to assign enterprise wide policies, deploy programs to many computers, and apply critical updates to an entire organization. Active Directory stores information about its users and can act in a similar manner to a phone book. This allows all of the information and computer settings about an organization to be stored in a central, organized database. Active Directory Networks can vary from a small installation with a few hundred objects, to a large installation with millions of objects.
Structure
An Active Directory (AD) structure is a hierarchical framework of objects. The objects fall into three broad categories - resources (e.g. printers), services (e.g. e-mail), and people (accounts, or users and groups). The AD provides information on the objects, organizes the objects, controls access, and sets security.
The objects represent single entities - whether users, computers, printers, applications, or shared data sources - and their attributes. Each object has a set of attributes, defined by and depending on its type and it is uniquely identified by its name.
At the top of the structure is the Forest, the collection of every object, their attributes and rules (attribute syntax) in the directory. The forest holds one or more transitive trust linked Trees. A tree holds one or more Domains, again linked in a transitive trust hierarchy. Domains are identified by their DNS name structure, the namespace.
The objects held within a domain can be logically grouped into containers called Organizational Units (OUs). OUs give a domain a hierarchy and ease administration, and give a semblance of the structure of the AD's company in organizational or geographical terms. OUs can contain OUs, indeed domains are containers in this sense and can hold multiple nested OUs. Microsoft recommends as few domains as possible in AD and a reliance on OUs to produce structure and policies. The OU is the common level at which to apply Group Policy settings, which are stored in Group Policy Objects (GPOs), although GPOs can also be applied to domains or sites (see below). The OU is the lowest level at which administrative powers can be delegated.
As a further subdivision AD supports the creation of Sites, which are physical, rather than logical, groupings defined by one or more IP subnets. Sites distinguish between locations connected by low-speed (e.g. WAN, VPN) and high-speed (e.g. LAN) connections. Sites can contain one or more domains and domains can contain one or more sites. This is important to control network traffic generated by replication.
The actual division of the company's information infrastructure into a hierarchy of one or more domains and top-level OUs is a key decision. Common models are by business, by geographical location, and by IT roles. Or by a combination of these models.
Physically the AD information is held on one or more equal peer domain controllers (DCs), replacing the NT PDC/BDC format (although there is a 'more equal' flexible single master operation (FSMO) server for some operations, which can simulate a PDC). Each DC holds a read-and-write copy of the AD, changes on one computer being synchronized (converged) between all the DC computers by multi-master replication . Servers without AD are called Member Servers.
AD replication is 'pull' rather than 'push'. The AD creates a replication topology that uses the defined sites to manage traffic. Intrasite replication is frequent and automatic through the Knowledge Consistency Checker (KCC), while intersite replication is configurable depending on the quality of each site link - a different 'cost' can be given to each link (e.g. DS3, T1, ISDN etc.) and replication traffic limited, scheduled, and routed accordingly. Replication data may be transitively passed through several sites on same-protocol site link bridges, if the 'cost' is low, although AD automatically costs a direct site-to-site link lower than transitive connections. Site-to-site replication is between a bridgehead server in each site, which then replicate the changes to other DCs within the site.
With more than one domain the AD is not replicated across the forest, a global catalog (GC) is created - containing all the objects in the Forest but only a limited subset of their attributes, a partial replica. The catalog is held on defined global catalog servers, to deal with inter-domain queries or pass requests across. Intra-domain convergence is by RPC over IP, forestwide convergence is by SMTP.
FSMO handles situations where multimaster replication would be inadequate. There are five FSMO tasks - the previously noted PDC emulation, relative ID master, and infrastructure master are domainwide roles; schema master and domain naming master are forestwide roles. In any domain there can be only one server handling a specific FSMO task.
The AD is split into three different stores or partitions. The Schema which is the template for the entire AD, defining all object types, their classes, attributes, and attribute syntax (all trees are together in the forest because they share an identical schema). The Configuration, which is the structure of the AD forest and trees. The Domain, which holds all the information on the object created in that domain. The first two stores replicate to all domain controllers, while only a portion of each domain store is shared - as the global catalog with other domain controllers - as the domain boundaries are the limits for full domain object replication.
The AD database, the directory store, in Windows 2000 uses the JET Blue-based Extensible Storage Engine (ESE98), limited to 16 terabytes and 1 billion objects in each domain controller's database (a theoretical limit, though only 100 million or more have been tested). Called NTDS.DIT it has two main tables - data table, link table. In Windows 2003 a third main table was added for security descriptor single instancing.
Naming
AD supports UNC (\), URL (/), and LDAP URL names for object access. AD internally uses the LDAP version of the X.500 naming structure. Every object has a Distinguished name (DN), so a printer object called HPLaser3 in the OU Marketing and the domain foo.org, would have the DN: 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) an unique and unchanging 128-bit string which is used by AD for search and replication. Certain objects also have a User principal name (UPN, from RFC 822), an objectname@domain name form.
Trust
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. As well as two-way transitive trust, AD trusts can be
shortcut (joins two domains in different trees, transitive, one- or two-way),
forest (transitive, one- or two-way),
realm (transitive or nontransitive, one- or two-way), or
external (nontransitive, one- or two-way) in order to connect to other forests or non-AD domains. AD uses the
Kerberos V5 protocol, although
NTLM is also supported and web clients use SSL/TLS.
See also
External links
Last updated: 08-28-2005 03:52:21
Last updated: 09-12-2005 02:39:13
