Jump to content

Active Directory

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Jeronim (talk | contribs) at 01:13, 30 January 2006 (→‎External links: removing scriptlogic advertisement). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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. An Active Directory stores information and settings relating to an organization in a central, organized, accessible 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.

Structure

Objects

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.

Each object represents a single entity — whether a user, a computer, a printer, an application, or a shared data source — and its attributes. Objects can also be containers of other objects. An object is uniquely identified by its name and has a set of attributes — the characteristics and information that the object can contain — defined by and depending on its type. The attributes, the basic structure of the object itself, are defined by a schema, which also determines the kind of objects that can be stored in the AD.

The schema itself is made up of two types of objects: schema class objects and schema attribute objects. A single 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 changing 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

Forests, Trees and Domains

The framework that holds the objects is viewed at a number of levels. At the top of the structure is the Forest - the collection of every object, its attributes and rules (attribute syntax) in the AD. The forest holds one or more transitive trust linked Trees. A tree holds one or more Domains and domain trees, again, linked in a transitive trust hierarchy. Domains are identified by their DNS name structure, the namespace. A domain has a single DNS name.

The objects held within a domain can be grouped into containers called Organizational Units (OUs). OUs give a domain a hierarchy, ease its administration, and can give a semblence of the structure of the AD's company in organisational 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 improve the implementation of policies and administration. The OU is the common level at which to apply group policies, which are AD objects themselves called Group Policy Objects (GPOs), although policies 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, or by IT roles. These models are also often used in combination.

Physical structure and Replication

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 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. Servers without AD are called Member Servers.

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.

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 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, only 100 million or so have been tested. NT4's Security Account Manager could support no more that 40,000 objects). Called NTDS.DIT, it has two main tables: the data table and the 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), 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.

Trusts in Windows 2000 (native mode)

Simply speaking, AD uses trust to allow users in one domain to have access to files in another. AD trust relationship is a mechanism by which users in one domain can be authenticated by another domain and then be allowed (or disallowed) access to resources within it. Each Windows-domain has implicit two-way transitive trust relationships with other domains. Such trusts are automatically maintained between domains. For example, if domain A trusts domain B, and B trusts C:

  • Domain A trusts domain C because trusts are transitive. Users from domain A can access files from domain C.
  • Domain C trusts domain A because trusts are two-way (and transitive). Users from domain C can access files from domain A.

And each domain can have explicit (manually created) trust relationships. Explicit trust can be:

  • Shortcut trust - joins any two domains within the same forest, for the shorten access time to resource. It’s transitive and one-way.
  • External trust – joins two domains in different forests, allows users from one forest to have access to resources from another forest. Its non-transitive, non-Kerberos and one-way.

See also

Notes

  1. ^ "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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Active_Directory&oldid=37289989"