Active Directory

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Typically Active Directory is managed using the graphical Microsoft Management

Console.

Active Directory (AD) is a technology created by Microsoft that provides a variety of

network services, including:

 LDAP-like[1][2] Directory services

 Kerberos based authentication
 DNS based naming and other network information

using the same database, for use primarily in Windows environments. Active Directory
also allows administrators to assign policies, deploy software, and apply critical updates
to an organization. Active Directory stores information and settings in a central 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 Server
edition, and revised to extend functionality and improve administration in Windows
Server 2003. Additional improvements were made in both Windows Server 2003 R2 and
Windows Server 2008.

Active Directory was called NTDS (NT Directory Service) in older Microsoft
documents. This name can still be seen in some AD binaries.

There is a common misconception that Active Directory provides software distribution.

Software distribution is run by a separate service that uses additional proprietary schema
attributes that work in conjunction with the LDAP protocol. Active Directory does not
automate software distribution, but provides a mechanism by which other services can
provide software distribution.

Contents
[hide]
 1 Structure
o 1.1 Objects
o 1.2 Forests, trees, and domains
 2 FSMO Roles
 3 Naming
 4 Trust
o 4.1 Trusts in Windows 2000 (native mode)
 5 ADAM/AD LDS
 6 Integrating Unix into Active Directory
 7 See also
 8 Notes

 9 External links

[edit] Structure
[edit] Objects

Active Directory is a directory service used to store information about the network
resources across a domain and also centralize the network.

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., email),
and users (user accounts 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, or a group
— and its attributes. Certain 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 a schema, which also determines
the kind of objects that can be stored in the AD.

Each attribute object can be used in several different schema class objects. These schema
objects 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 usually requires a fair amount of planning.[3]

[edit] Forests, trees, and domains

The framework that holds the objects can be 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, tree, and domain are the logical parts in an AD network.

The forest contains one or more transitive, trust-linked trees. A tree is a collection of one
or more domains and domain trees, 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 grouped into containers called Organizational
Units (OUs). OUs give a domain a hierarchy, ease its administration, and can 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 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 level at which administrative
powers are commonly delegated, but granular delegation can be performed on individual
objects or attributes as well.

AD also 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 are independent
of the domain and OU structure and are common across the entire forest. Sites are used to
control network traffic generated by replication and also to refer clients to the nearest
domain controllers. Exchange 2007 also uses the site topology for mail routing. Policies
can also be applied at the site level.

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 unit,
by geographical location, by IT Service, or by object type. These models are also often
used in combination. OUs should be structured primarily to facilitate administrative
delegation, and secondarily, to facilitate group policy application. Although OUs form an
administrative boundary, the only true security boundary is the forest itself and an
administrator of any domain in the forest must be trusted across all domains in the forest.

Physically the Active Directory information is held on one or more equal peer domain
controllers (DCs), replacing the NT PDC/BDC model. Each DC has a copy of the AD;
changes on one computer being synchronized (converged) between all the DC computers
by multi-master replication. Servers joined in to AD, which are not domain controllers,
are called Member Servers. The AD database is split into different stores or partitions.
Microsoft often refers to these partitions as 'naming contexts'. The 'Schema' partition
contains the definition of object classes and attributes within the Forest. The
'Configuration' partition, contains information on the physical structure and configuration
of the forest (such as the site topology). 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 subset
of objects in the domain partition are also replicated to domain controllers that are
configured as global catalogs.

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 Knowledge Consistency Checker (KCC)
creates a replication topology of site links using the defined sites to manage traffic.
Intrasite replication is frequent and automatic as a result of change notification, which
triggers peers to begin a pull replication cycle. Intersite replication intervals are less
frequent and do not use change notification by default, although this is configurable and
can be made identical to intrasite replication. A different 'cost' can be given to each link
(e.g., DS3, T1, ISDN etc.) and the site link topology will be altered accordingly by the
KCC. Replication between domain controllers may occur transitively through several site
links on same-protocol site link bridges, if the 'cost' is low, although KCC automatically
costs a direct site-to-site link lower than transitive connections. Site-to-site replication
can be configured to occur between a bridgehead server in each site, which then
replicates the changes to other DCs within the site.

In a multi-domain forest the AD database becomes partitioned. That is, each domain
maintains a list of only those objects that belong in that domain. So, for example, a user
created in Domain A would be listed only in Domain A's domain controllers. Global
catalog (GC) servers are used to provide a global listing of all objects in the Forest. The
Global catalog is held on domain controllers configured as global catalog servers. Global
Catalog servers replicate to themselves all objects from all domains and hence, provide a
global listing of objects in the forest. However, in order to minimize replication traffic
and to keep the GC's database small, only selected attributes of each object are replicated.
This is called the partial attribute set (PAS). The PAS can be modified by modifying the
schema and marking attributes for replication to the GC.

Replication of Active Directory uses Remote Procedure Calls (RPC over IP [RPC/IP]).
Between Sites you can also choose to use SMTP for replication, but only for changes in
the Schema or Configuration. SMTP cannot be used for replicating the Domain partition.
In other words, if a domain exists on both sides of a WAN connection, you must use
RPCs for 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. Microsoft has created NTDS databases with more than 2
billion objects.[citation needed] (NT4's Security Account Manager could support no more than
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.[4]
Active Directory is a necessary component for many Windows services in an
organization such as Exchange.

[edit] FSMO Roles

Flexible Single Master Operations (FSMO, sometimes pronounced "fizz-mo") roles are
also known as operations master roles. Although the AD domain controllers operate in a
multi-master model, i.e. updates can occur in multiple places at once, there are several
roles that are necessarily single instance:

Role Name Scope Description

Controls updates to the Schema its a collection of objects and

1 per all object which comes under AD that care taken by schema
Schema Master
forest master. DC will update all the process which comes under to
that DC.

Domain 1 per Controls the addition and removal of domains from the forest
Naming Master forest it present in root domain

Provides backwards compatibility for NT4 clients for PDC

operations (like password changes). The PDCs also run
1 per
PDC Emulator domain specific processes such as the Security Descriptor
domain
Propagator (SDPROP), and is the master time server within the
domain.

1 per Allocates pools of unique identifier to domain controllers for

RID Master
domain use when creating objects

Synchronizes cross-domain group membership changes. The

Infrastructure 1 per
infrastructure master cannot run on a global catalog server
Master domain
(unless all DCs are also GCs.)

[edit] 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), 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 name form.

[edit] Trust
To allow users in one domain to access resources in another, AD uses trusts. Trusts inside
a forest are automatically created when domains are created. The forest sets the default
boundaries of trust, not the domain, and implicit, transitive trust is automatic for all
domains within a forest. 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.

[edit] Trusts in Windows 2000 (native mode)

 One-way trust - One domain allows access to users on another domain, but the
other domain does not allow access to users on the first domain.
 Two-way trust - Two domains allow access to users on the other domain.
 Trusting domain - The domain that allows access to users from a trusted domain.
 Trusted domain - The domain that is trusted; whose users have access to the
trusting domain.
 Transitive trust - A trust that can extend beyond two domains to other trusted
domains in the tree.
 Intransitive trust - A one way trust that does not extend beyond two domains.
 Explicit trust - A trust that an admin creates. It is not transitive and is one way
only.
 Cross-link trust - An explicit trust between domains in different trees or in the
same tree when a descendant/ancestor (child/parent) relationship does not exist
between the two domains.

Windows 2000 - supports the following types of trusts:-

 Two-way transitive trusts.

 One-way intransitive trusts.

Additional trusts can be created by administrators. These trusts can be:

 Shortcut
Windows 2003 offers a new trust type - the forest root trust. This type of trust can be
used to connect Windows 2003 forests if they are operating at the 2003 forest functional
level. Authentication across this type of trust is Kerberos based (as opposed to NTLM).
Forest trusts are also transitive for all the domains in the forests that are trusted.

[edit] ADAM/AD LDS

Active Directory Application Mode (ADAM) is a light-weight implementation of
Active Directory. ADAM is capable of running as a service, on computers running
Microsoft Windows Server 2003 or Windows XP Professional. ADAM shares the code
base with Active Directory and provides the same functionality as Active Directory,
including an identical API, but does not require the creation of domains or domain
controllers.

Like Active Directory, ADAM provides a Data Store, which is a hierarchical datastore
for storage of directory data, a Directory Service with an LDAP Directory Service
Interface. Unlike Active Directory, however, multiple ADAM instances can be run on the
same server, with each instance having its own and required by applications making use
of the ADAM directory service.

In Windows Server 2008, ADAM has been renamed AD LDS (Lightweight Directory
Services).

[edit] Integrating Unix into Active Directory

Varying levels of interoperability with Active Directory can be achieved on most unix
like operating systems through standards compliant LDAP clients, but these systems
usually lack the automatic interpretation of many attributes, associated with windows
components such as Group Policy and support for one-way trusts.

There are also third-party vendors who offer Active Directory integration for Unix
platforms (including UNIX, Linux, Mac OS X, and a number of Java- and UNIX-based
applications). Some of these vendors include Thursby Software Systems (ADmitMac),
Quest Software (Vintela Authentication Services), Centrify (DirectControl), and
Likewise Software (Likewise Open and Likewise Enterprise). Microsoft is also in this
market with their free Microsoft Windows Services for UNIX product.

The schema additions shipped with Windows Server 2003 release 2 include attributes that
map closely enough to RFC 2307 to be generally usable. The reference implementation
of RFC 2307, nss_ldap and pam_ldap provided by PADL.com, contains support for using
these attributes directly, provided they have been populated. The default Active Directory
schema for group membership complies with the proposed extension, RFC 2307bis.
RFC2307bis specifies storing Unix group membership using LDAP member attributes as
opposed to the base RFC 2307 which specified storing group membership as a comma-
separate list of user IDs (as was done in the Unix group file). Windows 2003R2 includes
an MMC snap-in that creates and edits the attributes.

An alternate option is to use another directory service such as Fedora Directory Server
(formerly Netscape Directory Server) or Sun Microsystems Sun Java System Directory
Server, which can perform a two-way synchronization with Active Directory and thus
provide a "deflected" integration with Active Directory as Unix and Linux clients will
authenticate to FDS and Windows Clients will authenticate to Active Directory. Another
option is to use OpenLDAP with its translucent overlay, which can extend entries in any
remote LDAP server with additional attributes stored in a local database. Clients pointed
at the local database will see entries containing both the remote and local attributes, while
the remote database remains completely untouched.

Samba 4, still in testing state as of August 8, 2008, plans to include an Active Directory
compatible server.

[edit] See also

 Active Directory Explorer
 Directory Services Restore Mode
 Flexible single master operation
 List of LDAP software

[edit] Notes
1. ^ eDirectory vs Active Directory
2. ^ ADAM vs LDAP
3. ^ (2003) Windows Server 2003: Active Directory Infrastructure. Microsoft Press, 1-8 –
1-9. ISBN 0-7356-1438-5.
4. ^ Large AD database? Probably not this large...

[edit] External links

 Microsoft's Active Directory Page
 Active Directory Application Mode (ADAM)

 Active Directory Explorer

[show]
v•d•e
Microsoft

[show]
v•d•e
 Microsoft Windows components

Retrieved from "http://en.wikipedia.org/wiki/Active_Directory"

Categories: Active Directory | Identity management systems | Microsoft server
technology | Windows components
Hidden categories: All articles with unsourced statements | Articles with unsourced
statements since January 2008