Active Directory
Active Directory is a technology created by Microsoft that provides a variety of network services, including:
• LDAP-like directory services
• Kerberos-based authentication
• DNS-based naming and other network information
• Central location for network administration and delegation of authority
• Information security and single sign-on for user access to networked based resources
• The ability to scale up or down easily
• Central storage location for application data
• Synchronization of directory updates amongst several servers
• 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 computers, users and printers to tens of thousands of users, many different domains and large server farms spanning many geographical locations.
Active Directory was previewed in 1999, released first with Windows 2000 Server edition, and revised to extend functionality and improve administration in Windows Server 2003. Additional improvements were made in Windows Server 2003 R2. Active Directory was refined further in Windows Server 2008 and Windows Server 2008 R2 and was renamed Active Directory Domain Services.
Active Directory was called NTDS (NT Directory Service) in older Microsoft documents. This name can still be seen in some Active Directory binaries.
Contents
• 1 Structure
o 1.1 Objects
o 1.1.1 Sites
o 1.2 Forests, trees, and domains
1.2.1 Flat-filed, simulated hierarchy
1.2.2 Structural divisions to improve performance
• 2 FSMO Roles
• 3 Trust
o 3.1 Trusts in Windows 2000 (native mode)
• 4 ADAM/AD LDS
• 5 Integrating Unix into Active Directory
• 6 Replacement with other directories
• 7 See also
• 8 Notes
• 9 External links
Structure
Objects
Everything that Active Directory tracks is considered an object. An object is any user, system, resource, or service tracked within Active Directory. The generic term object is used because Active Directory is capable of tracking a variety of items, and many objects can share common attributes.
An Active Directory structure is a hierarchical framework of objects. The objects fall into two broad categories: resources (e.g., printers) and security principals (user or computer accounts and groups). Security principals are Active Directory objects that are assigned unique security identifiers (SIDs) used to control access and set 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 Active Directory.
Each attribute object can be used in several different schema class objects. The schema object exists to allow the schema to be extended or modified when necessary. However, because each schema object is integral to the definition of Active Directory objects, deactivating or changing these objects can have serious consequences because it will fundamentally change the structure of Active Directory 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.[2]
Sites
A Site object in Active Directory represents a physical geographic location that hosts networks. Sites contain objects called subnets.[3] Sites can be used to assign Group Policy Objects, facilitate the discovery of resources, manage active directory replication, and manage network link traffic. Sites can be linked to other Sites. Site-linked objects may be assigned a cost value that represents the speed, reliability, availability, or other real property of a physical resource. Site Links may also be assigned a schedule.
Forests, trees, and domains
Forest-WidgetsCorp
Tree-Eastern
Domain-Boston
Domain-NewYork
Domain-Philly
Tree-Southern
Domain-Atlanta
Domain-Dallas
Domain-Dallas
OU-Marketing
Donn
Mark
Steve
OU-Sales
Bill
Ralph
Example of the geographical organizing of zones of interest within trees and domains.
The Active Directory framework that holds the objects can be viewed at a number of levels. At the top of the structure is the forest. The forest is a collection of every object, its attributes, and rules (attribute syntax) in the Active Directory. The forest, tree, and domain are the logical parts in an Active Directory network.
The Active Directory 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.
Flat-filed, simulated hierarchy
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 resemblance of the structure of the organization 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 Active Directory 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 Active Directory 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.
However, Organizational Units are just an abstraction for the administrator, and do not function as true containers; the underlying domain operates as if objects were all created in a simple flat-file structure, without any OUs. It is not possible for example to create two user accounts with an identical username in two separate OUs, such as "fred.staff-ou.domain" and "fred.student-ou.domain".
By contrast, LDAP and Novell eDirectory are true hierarchical directories, allowing account name duplication across separate OUs. Each user logs in by specifying the context of their account, which is similar to the current working directory of a file system. Context normally operates in relative form: if the login prompt context is "staff-ou.accounts-ou.organization", people with accounts in that specific OU need only type their username "fred". But if the login prompt context were set to be one level higher, at "accounts-ou.organization", people would need to specify the OU within that context: "fred.staff-ou". Context can also be specified in absolute form similar to an absolute directory path by using a leading period: ".fred.staff-ou.accounts-ou.organization", which disregards the current login prompt context.
Novell additionally provides login prompt functionality known as contextless login[4] to permit searching the directory structure via LDAP for all possible matching or similar usernames, making the Novell login process operate similar to Microsoft's flat-file structure that searches the entire domain for accounts regardless of the account's location in the OUs. The concept of account context in the directory does not apply to Active Directory, since object name duplication within a single domain is not permitted to occur in the first place.
Because duplicate usernames cannot exist within separate OUs of a single active directory domain, unique account name generation poses a significant challenge for organizations with hundreds to thousands of users that are part of a generalized mass that can not be easily subdivided into separate domains, such as students in a public school system or univeristy that must be able to login on any computer across the district buildings or campus network.
As the number of users in a domain increases, simple username creation methods such as "first initial, middle initial, last name" will fail due to having so many common names like Smith or Johnson in the collective mass that result in having duplications, such as two JASmith, which requires randomly adding a number to the end (JASmith1) to further differentiate it for one of the two people. At some point of increasingly many users and name duplications, the network IT staff may give up on attempts at making usernames personally memorable, and the username simply becomes a serial number 5 to 10 digits long to provide sufficient naming uniqueness within a single domain.
Structural divisions to improve performance
Active Directory 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 an organization'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 Active Directory; changes on one computer being synchronized (converged) between all the DC computers by multi-master replication. Servers joined to Active Directory that are not domain controllers are called Member Servers.
The Active Directory 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.
Active Directory 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 uses 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 Active Directory 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 Active Directory database, the directory store, in Windows 2000 Server 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 Server 2003 a third main table was added for security descriptor single instancing.[5]
Active Directory is a necessary component for many Windows services in an organization such as Exchange.
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
Schema Master 1 per forest Controls and handles updates/modifications to the Active Directory schema.
Domain Naming Master 1 per forest Controls the addition and removal of domains from the forest if present in root domain
PDC Emulator 1 per domain Provides backwards compatibility for NT4 clients for PDC operations (like password changes). The PDCs also run domain specific processes such as the Security Descriptor Propagator (SDPROP), and is the master time server within the domain.
RID Master 1 per domain Allocates pools of unique identifier to domain controllers for use when creating objects
Infrastructure Master 1 per domain/partition Synchronizes cross-domain group membership changes. The infrastructure master cannot run on a global catalog server (GCS)(unless all DCs are also GCs.)
Trust
To allow users in one domain to access resources in another, Active Directory 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 a shortcut (joins two domains in different trees, transitive, one- or two-way), forest (transitive, one- or two-way), realm (transitive or non-transitive, one- or two-way), or external (non-transitive, one- or two-way) in order to connect to other forests or non-AD domains.
Windows Server 2003 offers a new trust type – the forest root trust. This type of trust can be used to connect Windows Server 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.
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 Centrify (DirectControl), Computer Associates (UNAB), Likewise Software (Open or Enterprise), Quest Software (Authentication Services) and Thursby Software Systems (ADmitMac). The open source Samba software provides a way to interface with Active Directory and join the AD domain to provide authentication and authorization: version 4 (in alpha as of October 2009[update]) can act as a peer Active Directory domain controller.[7]. Microsoft is also in this market with their free Microsoft Windows Services for UNIX product.
The schema additions shipped with Windows Server 2003 R2 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. Windows Server 2003 R2 includes a Microsoft Management Console snap-in that creates and edits the attributes.
An alternate option is to use another directory service such as 389 Directory Server (formerly Fedora 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.
Replacement with other directories
Active Directory and a Windows-based file server are not required to implement roaming user profiles on client Windows computers. For example, the directory can be fully replaced by competitor products such as Novell edirectory. Novell has supported roaming profiles since Windows 2000 with their ZEN works Desktop Management software package, and starting with Windows XP also supports group policy objects, in addition to providing workstation management features such as remote view/control, remote application installation, and inventorying of installed hardware and software. With the Novell client installed, roaming profile data may also be stored on a Netware file server using the Netware Core Protocol, though a Novell server also permits creation of Windows shares.
There are certain differences in operation when using non-Microsoft directories:
• Novell permits duplicate usernames within different organizational units, which Active Directory does not support.
• Novell stores Windows 2000 and Windows XP user profiles in separate folders, similar to how Microsoft uses separate storage for XP and Vista profiles.
• Offline folders are not possible using NCP.
• A Windows client normally checks the roaming user's SID for profile ownership during login but this can be disabled to work with other directories.
The Lightweight Directory Access Protocol, or LDAP, is an application protocol for querying and modifying data using directory services running over TCP/IP
A directory is a set of objects with attributes organized in a logical and hierarchical manner. A simple example is the telephone directory, which consists of a list of names (of either persons or organizations) organized alphabetically, with each name having an address and phone number associated with it.
An LDAP directory tree often reflects various political, geographic, and/or organizational boundaries, depending on the model chosen. LDAP deployments today tend to use Domain Name System (DNS) names for structuring the topmost levels of the hierarchy. Deeper inside the directory might appear entries representing people, organizational units, printers, documents, groups of people or anything else that represents a given tree entry (or multiple entries).
Its current version is LDAPv3, which is specified in a series of Internet Engineering Task Force (IETF) Standard Track Requests for comments (RFCs) as detailed in RFC 4510
Telecommunication companies introduced the concept of directory services to information technology and computer networking, since their understanding of directory requirements was well-developed after some 70 years of producing and managing telephone directories. The culmination of this input was the comprehensive X.500 specification[2], a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s.
X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol (DAP), which required the Open Systems Interconnection (OSI) protocol stack. LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP protocol stack. This model of directory access was borrowed from the DIXIE and Directory Assistance Service protocols.
Standalone LDAP directory servers soon followed, as did directory servers supporting both DAP and LDAP. The latter has become popular in enterprises, as LDAP removed any need to deploy an OSI network. Today, X.500 directory protocols including DAP can also be used directly over TCP/IP.
The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille of Isode Limited, and Wengyik Yeong of Performance Systems International, circa 1993. Further development has come through the Internet Engineering Task Force.
In the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol, or LDBP. It was renamed with the expansion of the scope of the protocol to include beyond directory browsing and searching functions, also directory update functions. It was given its Lightweight name because it was not as network intensive as its DAP predecessor and thus was more easily implemented over the internet due to its lightweight bandwidth usage.
LDAP has influenced subsequent Internet protocols, including later versions of X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol (SLP).
Protocol overview
A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by default on TCP port 389. The client then sends an operation request to the server, and the server sends responses in return. With some exceptions, the client does not need to wait for a response before sending the next request, and the server may send the responses in any order.
The client may request the following operations:
• Start TLS — use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection
• Bind — authenticate and specify LDAP protocol version
• Search — search for and/or retrieve directory entries
• Compare — test if a named entry contains a given attribute value
• Add a new entry
• Delete an entry
• Modify an entry
• Modify Distinguished Name (DN) — move or rename an entry
• Abandon — abort a previous request
• Extended Operation — generic operation used to define other operations
• Unbind — close the connection (not the inverse of Bind)
Directory structure
The protocol accesses LDAP directories, which follow the 1993 edition of the X.500 model:
• A directory is a tree of directory entries.
• An entry consists of a set of attributes.
• An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema (see below).
• Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN), constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as the full file path and the RDN as its relative filename in its parent folder (e.g. if C:\foo\bar\myfile.txt were the DN, then myfile.txt would be the RDN).
Be aware that a DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a UUID might be provided in the set of the entry's operational attributes.
An entry can look like this when represented in LDAP Data Interchange Format (LDIF) (LDAP itself is a binary protocol):
Active Directory is a technology created by Microsoft that provides a variety of network services, including:
• LDAP-like directory services
• Kerberos-based authentication
• DNS-based naming and other network information
• Central location for network administration and delegation of authority
• Information security and single sign-on for user access to networked based resources
• The ability to scale up or down easily
• Central storage location for application data
• Synchronization of directory updates amongst several servers
• 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 computers, users and printers to tens of thousands of users, many different domains and large server farms spanning many geographical locations.
Active Directory was previewed in 1999, released first with Windows 2000 Server edition, and revised to extend functionality and improve administration in Windows Server 2003. Additional improvements were made in Windows Server 2003 R2. Active Directory was refined further in Windows Server 2008 and Windows Server 2008 R2 and was renamed Active Directory Domain Services.
Active Directory was called NTDS (NT Directory Service) in older Microsoft documents. This name can still be seen in some Active Directory binaries.
Contents
• 1 Structure
o 1.1 Objects
o 1.1.1 Sites
o 1.2 Forests, trees, and domains
1.2.1 Flat-filed, simulated hierarchy
1.2.2 Structural divisions to improve performance
• 2 FSMO Roles
• 3 Trust
o 3.1 Trusts in Windows 2000 (native mode)
• 4 ADAM/AD LDS
• 5 Integrating Unix into Active Directory
• 6 Replacement with other directories
• 7 See also
• 8 Notes
• 9 External links
Structure
Objects
Everything that Active Directory tracks is considered an object. An object is any user, system, resource, or service tracked within Active Directory. The generic term object is used because Active Directory is capable of tracking a variety of items, and many objects can share common attributes.
An Active Directory structure is a hierarchical framework of objects. The objects fall into two broad categories: resources (e.g., printers) and security principals (user or computer accounts and groups). Security principals are Active Directory objects that are assigned unique security identifiers (SIDs) used to control access and set 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 Active Directory.
Each attribute object can be used in several different schema class objects. The schema object exists to allow the schema to be extended or modified when necessary. However, because each schema object is integral to the definition of Active Directory objects, deactivating or changing these objects can have serious consequences because it will fundamentally change the structure of Active Directory 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.[2]
Sites
A Site object in Active Directory represents a physical geographic location that hosts networks. Sites contain objects called subnets.[3] Sites can be used to assign Group Policy Objects, facilitate the discovery of resources, manage active directory replication, and manage network link traffic. Sites can be linked to other Sites. Site-linked objects may be assigned a cost value that represents the speed, reliability, availability, or other real property of a physical resource. Site Links may also be assigned a schedule.
Forests, trees, and domains
Forest-WidgetsCorp
Tree-Eastern
Domain-Boston
Domain-NewYork
Domain-Philly
Tree-Southern
Domain-Atlanta
Domain-Dallas
Domain-Dallas
OU-Marketing
Donn
Mark
Steve
OU-Sales
Bill
Ralph
Example of the geographical organizing of zones of interest within trees and domains.
The Active Directory framework that holds the objects can be viewed at a number of levels. At the top of the structure is the forest. The forest is a collection of every object, its attributes, and rules (attribute syntax) in the Active Directory. The forest, tree, and domain are the logical parts in an Active Directory network.
The Active Directory 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.
Flat-filed, simulated hierarchy
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 resemblance of the structure of the organization 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 Active Directory 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 Active Directory 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.
However, Organizational Units are just an abstraction for the administrator, and do not function as true containers; the underlying domain operates as if objects were all created in a simple flat-file structure, without any OUs. It is not possible for example to create two user accounts with an identical username in two separate OUs, such as "fred.staff-ou.domain" and "fred.student-ou.domain".
By contrast, LDAP and Novell eDirectory are true hierarchical directories, allowing account name duplication across separate OUs. Each user logs in by specifying the context of their account, which is similar to the current working directory of a file system. Context normally operates in relative form: if the login prompt context is "staff-ou.accounts-ou.organization", people with accounts in that specific OU need only type their username "fred". But if the login prompt context were set to be one level higher, at "accounts-ou.organization", people would need to specify the OU within that context: "fred.staff-ou". Context can also be specified in absolute form similar to an absolute directory path by using a leading period: ".fred.staff-ou.accounts-ou.organization", which disregards the current login prompt context.
Novell additionally provides login prompt functionality known as contextless login[4] to permit searching the directory structure via LDAP for all possible matching or similar usernames, making the Novell login process operate similar to Microsoft's flat-file structure that searches the entire domain for accounts regardless of the account's location in the OUs. The concept of account context in the directory does not apply to Active Directory, since object name duplication within a single domain is not permitted to occur in the first place.
Because duplicate usernames cannot exist within separate OUs of a single active directory domain, unique account name generation poses a significant challenge for organizations with hundreds to thousands of users that are part of a generalized mass that can not be easily subdivided into separate domains, such as students in a public school system or univeristy that must be able to login on any computer across the district buildings or campus network.
As the number of users in a domain increases, simple username creation methods such as "first initial, middle initial, last name" will fail due to having so many common names like Smith or Johnson in the collective mass that result in having duplications, such as two JASmith, which requires randomly adding a number to the end (JASmith1) to further differentiate it for one of the two people. At some point of increasingly many users and name duplications, the network IT staff may give up on attempts at making usernames personally memorable, and the username simply becomes a serial number 5 to 10 digits long to provide sufficient naming uniqueness within a single domain.
Structural divisions to improve performance
Active Directory 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 an organization'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 Active Directory; changes on one computer being synchronized (converged) between all the DC computers by multi-master replication. Servers joined to Active Directory that are not domain controllers are called Member Servers.
The Active Directory 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.
Active Directory 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 uses 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 Active Directory 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 Active Directory database, the directory store, in Windows 2000 Server 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 Server 2003 a third main table was added for security descriptor single instancing.[5]
Active Directory is a necessary component for many Windows services in an organization such as Exchange.
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
Schema Master 1 per forest Controls and handles updates/modifications to the Active Directory schema.
Domain Naming Master 1 per forest Controls the addition and removal of domains from the forest if present in root domain
PDC Emulator 1 per domain Provides backwards compatibility for NT4 clients for PDC operations (like password changes). The PDCs also run domain specific processes such as the Security Descriptor Propagator (SDPROP), and is the master time server within the domain.
RID Master 1 per domain Allocates pools of unique identifier to domain controllers for use when creating objects
Infrastructure Master 1 per domain/partition Synchronizes cross-domain group membership changes. The infrastructure master cannot run on a global catalog server (GCS)(unless all DCs are also GCs.)
Trust
To allow users in one domain to access resources in another, Active Directory 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 a shortcut (joins two domains in different trees, transitive, one- or two-way), forest (transitive, one- or two-way), realm (transitive or non-transitive, one- or two-way), or external (non-transitive, one- or two-way) in order to connect to other forests or non-AD domains.
Windows Server 2003 offers a new trust type – the forest root trust. This type of trust can be used to connect Windows Server 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.
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 Centrify (DirectControl), Computer Associates (UNAB), Likewise Software (Open or Enterprise), Quest Software (Authentication Services) and Thursby Software Systems (ADmitMac). The open source Samba software provides a way to interface with Active Directory and join the AD domain to provide authentication and authorization: version 4 (in alpha as of October 2009[update]) can act as a peer Active Directory domain controller.[7]. Microsoft is also in this market with their free Microsoft Windows Services for UNIX product.
The schema additions shipped with Windows Server 2003 R2 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. Windows Server 2003 R2 includes a Microsoft Management Console snap-in that creates and edits the attributes.
An alternate option is to use another directory service such as 389 Directory Server (formerly Fedora 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.
Replacement with other directories
Active Directory and a Windows-based file server are not required to implement roaming user profiles on client Windows computers. For example, the directory can be fully replaced by competitor products such as Novell edirectory. Novell has supported roaming profiles since Windows 2000 with their ZEN works Desktop Management software package, and starting with Windows XP also supports group policy objects, in addition to providing workstation management features such as remote view/control, remote application installation, and inventorying of installed hardware and software. With the Novell client installed, roaming profile data may also be stored on a Netware file server using the Netware Core Protocol, though a Novell server also permits creation of Windows shares.
There are certain differences in operation when using non-Microsoft directories:
• Novell permits duplicate usernames within different organizational units, which Active Directory does not support.
• Novell stores Windows 2000 and Windows XP user profiles in separate folders, similar to how Microsoft uses separate storage for XP and Vista profiles.
• Offline folders are not possible using NCP.
• A Windows client normally checks the roaming user's SID for profile ownership during login but this can be disabled to work with other directories.
The Lightweight Directory Access Protocol, or LDAP, is an application protocol for querying and modifying data using directory services running over TCP/IP
A directory is a set of objects with attributes organized in a logical and hierarchical manner. A simple example is the telephone directory, which consists of a list of names (of either persons or organizations) organized alphabetically, with each name having an address and phone number associated with it.
An LDAP directory tree often reflects various political, geographic, and/or organizational boundaries, depending on the model chosen. LDAP deployments today tend to use Domain Name System (DNS) names for structuring the topmost levels of the hierarchy. Deeper inside the directory might appear entries representing people, organizational units, printers, documents, groups of people or anything else that represents a given tree entry (or multiple entries).
Its current version is LDAPv3, which is specified in a series of Internet Engineering Task Force (IETF) Standard Track Requests for comments (RFCs) as detailed in RFC 4510
Telecommunication companies introduced the concept of directory services to information technology and computer networking, since their understanding of directory requirements was well-developed after some 70 years of producing and managing telephone directories. The culmination of this input was the comprehensive X.500 specification[2], a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s.
X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol (DAP), which required the Open Systems Interconnection (OSI) protocol stack. LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP protocol stack. This model of directory access was borrowed from the DIXIE and Directory Assistance Service protocols.
Standalone LDAP directory servers soon followed, as did directory servers supporting both DAP and LDAP. The latter has become popular in enterprises, as LDAP removed any need to deploy an OSI network. Today, X.500 directory protocols including DAP can also be used directly over TCP/IP.
The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille of Isode Limited, and Wengyik Yeong of Performance Systems International, circa 1993. Further development has come through the Internet Engineering Task Force.
In the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol, or LDBP. It was renamed with the expansion of the scope of the protocol to include beyond directory browsing and searching functions, also directory update functions. It was given its Lightweight name because it was not as network intensive as its DAP predecessor and thus was more easily implemented over the internet due to its lightweight bandwidth usage.
LDAP has influenced subsequent Internet protocols, including later versions of X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol (SLP).
Protocol overview
A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by default on TCP port 389. The client then sends an operation request to the server, and the server sends responses in return. With some exceptions, the client does not need to wait for a response before sending the next request, and the server may send the responses in any order.
The client may request the following operations:
• Start TLS — use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection
• Bind — authenticate and specify LDAP protocol version
• Search — search for and/or retrieve directory entries
• Compare — test if a named entry contains a given attribute value
• Add a new entry
• Delete an entry
• Modify an entry
• Modify Distinguished Name (DN) — move or rename an entry
• Abandon — abort a previous request
• Extended Operation — generic operation used to define other operations
• Unbind — close the connection (not the inverse of Bind)
Directory structure
The protocol accesses LDAP directories, which follow the 1993 edition of the X.500 model:
• A directory is a tree of directory entries.
• An entry consists of a set of attributes.
• An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema (see below).
• Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN), constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as the full file path and the RDN as its relative filename in its parent folder (e.g. if C:\foo\bar\myfile.txt were the DN, then myfile.txt would be the RDN).
Be aware that a DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a UUID might be provided in the set of the entry's operational attributes.
An entry can look like this when represented in LDAP Data Interchange Format (LDIF) (LDAP itself is a binary protocol):
No comments:
Post a Comment