Active Directory
|
|
Active Directory (codename Cascade) is an implementation of LDAP directory services by Microsoft for use in Windows environments. 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.
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.
| Contents |
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 is uniquely identified by its name and has a set of attributes, or characteristics and information that the object can contain, defined by and depending on its type. Objects can also be containers of other objects. Each object is defined by a schema, which determines the kind of objects that can be stored in AD, and the basic structure of the object itself. The schema itself is made up of two types of objects: schema class objects and schema attribute objects. A schema class object defines one type of object that can be created by AD — for instance, it allows a User object to be created — and a schema attribute object defines an attribute that objects can have. Each attribute object can be used in several different schema class objects. Those objects are known as schema objects, or metadata, and exist to allow the schema to be extended or modified when necessary. However, because each schema object is integral to the definition of AD objects, deactivating or change these objects can have serious consequences because it will fundamentally change the structure of AD itself. A schema object, when altered, will automatically propagate through Active Directory and once it is created it can only be deactivated — not deleted. Changing the schema is not something that is usually done without some planning. Template:Ref
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
See also
- Active Directory Service Interfaces
- Open Directory Services Interface
- Windows Open System Architecture
- Directory Enabled Networks
- Microsoft Directory Synchronization Services
- Group Policy
Notes
- Template:Note "Windows Server 2003: Active Directory Infrastructure" (2003). Microsoft Press. pg 1-8 – 1-9.
References
- "Windows Server 2003: Active Directory Infrastructure" (2003). Microsoft Press. ISBN 0-7356-1438-5.
External links
- Microsoft's Active Directory Page (http://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.mspx)
- Microsoft (http://www.microsoft.com)
- SRV records (http://www.opentechsupport.net/forums/archive/topic/16708-1.html)
- WINS (Windows Internet Naming Service) (http://www.windowsitlibrary.com/Content/155/09/1.html)
- Distributed Management Task Force (http://www.dmtf.org)de:Active Directory Service