When examining AD DS for the first time, it's easiest to examine the domain first because so much of the basis of AD DS is derived from the domain. It's adequate to boil down the function of domains into three basic areas:
Consolidating lists of usernames and passwords for all machines within a domain and providing an infrastructure for using that consolidated list
Providing a method of subdividing objects within a domain for easier administration (into OUs, as described earlier)
Offering a centralized, searchable list of resources within the domain so that users and administrators can easily query that list to find objects they need
Domains, at a minimum, keep a list of all authorized users and their passwords on a machine or groups of machines called domain controllers. This list is stored in AD DS. However, many other objects are stored within the directory—which is actually a file on a domain controller's hard drive called NTDS.DIT—including sites, OUs, groups of users, groups of computers, GPOs (described in Chapter 6), and contacts, just to name a few.
The engine that drives this database of information is the same engine within Microsoft's powerhouse Exchange Server product, and it supports the transmission of database contents to multiple domain controllers over network links—a process called replication. Replication answers the question of how multiple domain controllers within a domain can contain the same information. For example, if you have a domain controller in Seattle and another in Charlotte, and you were to add a user in Charlotte, what if that user tried to log on to a computer in Seattle? How would the Seattle domain controller know about the user added in Charlotte? Replication allows AD DS to transmit changed data across a domain to all relevant domain controllers so that the contents of the directory are always up-to-date on each domain controller.
At this point, astute readers who are familiar with the domain structure of Microsoft's Windows NT products surely are asking, "What about PDCs and BDCs?" For the most part, Microsoft has removed that designation from domain controllers in AD DS environments, meaning that with only a couple of minor exceptions, all domain controllers are equal. This is referred to as a multimaster environment.
Because a domain controller holds a large database of information, AD DS has some interesting characteristics that weren't necessarily true of NT 4.0's Security Accounts Manager (SAM)-based list of accounts. For instance, programmers can write code to interface directly with AD DS and run queries to pull data from the database. These programmers can use either the Lightweight Directory Access Protocol (LDAP), an industry-standard protocol for accessing any sort of directory, or the Microsoft-specific Active Directory Services Interface (ADSI) for taking advantage of AD DS features not supported directly within the LDAP specification. Additionally, AD DS doesn't have the same size limitations that the SAM had. AD DS easily can handle up to a few million objects, as compared to the SAM's ability to handle no more than about 5,000 accounts. (That's scalability, folks!) AD DS is also fast when handling large amounts of data, so you won't get bogged down when your directory grows.
*.* Source of Information : O'Reilly Windows Server 2008: The Definitive Guide
No comments:
Post a Comment