The Importance of a Domain - The Main Event—Active Directory (Page 5 of 11 )
We've gone into quite a bit of detail on how domains used to work before the Active Directory and this is necessary as in many situations you will be upgrading from an NT 4-based domain environment. Understanding its structure and limitations is vital when designing your new infrastructure. You need to understand the old limitations to appreciate how and why they shaped your existing structure, but these limitations no longer apply and so should not be a major factor in your new design which can be designed around business requirements and operational best practices rather than technical limitations.
Windows NT 4 SAM-based domains meet our definition of a domain: a set of machines sharing a common security database and the Security Accounts Manager (SAM) was used to manage security accounts. Other applications could sometimes leverage this authentication but it could not be used for anything else; it was not a directory service.
Microsoft realized that to compete with other Network Operating Systems it had to offer a real directory service, something that:
- Is based on the IEEE X.500 Directory Services Implementation
- Can be accessed via standard methods such as LDAP
- Can store information about all aspects of a business including applications and resources, not just users
- Can be modified to include custom attributes
- Can be fully searchable
- Allows very granular delegation of duties
- Can be scalable
One option would have been to upgrade the current domain implementation but in truth it was not a good foundation and the upgrade probably would have been more work than starting from scratch. As it turned out, Microsoft had a better starting point: Exchange.
Exchange had its own directory service for storing mailbox and distribution list information, which supported some industry standards for its interface, and so Microsoft took this directory service as a starting point.
The Directory Service Implementation
A Directory Service has to store the data and provide an interface to access the data, the same as a telephone directory service; it has a big database of all the numbers and then provides a phone number or internet page you can use to access the data.
A directory service really has to comprise three things:
- A method to store and arrange the data
- A method to locate the data
- A method to access the data
Fortunately for Microsoft, it was not inventing the concept of directory services and there were many industry standards that had been tried and tested in other implementations. By adhering to industry standards this also provided a benefit to the customer who might already have directory service tools, and allowed a far simpler migration to the Active Directory.
For the storage model of the Active Directory, the common IEEE X.500 Directory Services implementation was chosen as a standard. X.500 provides a hierarchical structure named the directory information tree (or DIT for short), which contains a number of objects, each of which comprises one or more attributes (the actual objects and applicable attributes are described in the schema, which we'll discuss shortly). One important component of X.500 is the organizational unit that can contain other objects and even other organizational units; this is a crucial component for creating a directory service that can mimic your business model.
The following figure shows an X.500 structure with the organization broken down into three countries each having its own organizational unit structures containing objects (in this case, some users).
Each object in the DIT has two names; one is an unambiguous name, the distinguished name (DN), defining the name and exact location of the object. The other is a relative distinguished name (RDN) which only contains the name of the object relative to its position in the tree.
An example of a distinguished name would be:
CN=John Savill, OU=IT, DC=savilltech, DC=com
This shows an object by the name of John Savill in an Organizational Unit called IT in a domain called savilltech.com. Its RDN would be just "John Savill".
The actual data for the domain is now stored in a file called NTDS.DIT that is stored in the %systemroot%NTDS folder by default. This file is based on the Microsoft Extensible Storage Engine (ESE) as used by Exchange. This new implementation throws away the old 40MB limit and a single domain can now hold millions of objects. The theoretical limit (of 4.3 billion objects) is caused by the Global Catalog and addressing issues of the i386 architecture. We will explore Global Catalog further on in the chapter.
The next issue is how to access the data in the directory. X.500 has its own Directory Access Protocol (or DAP). However, it is very large and cumbersome to implement. For this reason another IEEE industry-standard access protocol was created, LDAP, the Lightweight Directory Access Protocol, containing a subset of the full X.500 protocol.
There have been a number of versions of LDAP. However, Active Directory implements version 3 of LDAP (although it also provides backwards compatibility for version 2) and this use of an industry standard for the access mechanism allows access to the information from practically any network-enabled environment. Another advantage is that unlike X.500 (which is based around the OSI model), LDAP has full support for TCP/IP, which is obviously very useful for any kind of Internet-aware service.
LDAP operates over two main ports, port 389 for standard LDAP and port 636 for secure LDAP. Since Active Directory now provides an LDAP server, it operates over both of these ports. Anyone trying to run Exchange 5.5 on an Active Directory domain controller will face problems, since Exchange 5.5 also has an LDAP server, which tries to use port 389 and thus fails to start since Windows has already reserved it.
There are numerous interfaces to LDAP, including a programmatic API for the C programming language, because LDAP is a standard for communication between directory services, for example between a NetWare Directory Service and an Active Directory implementation. Microsoft also offers its Active Directory Services Interface (or ADSI) which offers a simple interface in communication with the Active Directory.
Microsoft went beyond the core standard version 3 of LDAP and included support for:
- Dynamic Store entries, which basically allow entries in the directory to have Time To Live (TTL) values so they can be automatically deleted (RFC 2589)
- Transport Layer Security (TLS) connection support over LDAP (RFC 2830)
- Digest Authentication (RFC 2829), which allows connection to the Active Directory to be authenticated using the DIGEST-MD5 Simple Authentication and Security Layer (SASL) authentication mechanism
- Virtual List Views (VLV), which allow clients to pull down a subset or window of results when the total result set is too large for the client to handle
- Support for InetOrgPerson class (RFC 2798); passwords can also be set on InetOrgPerson objects under Windows 2003 implementations
- Use of domains in LDAP distinguished names (RFC 2247)
- Server-side sorting of search results (RFC 2891)
- Concurrent LDAP Binds, which allow an application to bind to LDAP
multiple times via one connection While these are all functions above the core LDAP version 3, they are all still standards and should therefore be fully supported by most LDAP client implementations.
Support for the above was required to improve the whole directory service experience and provide true additional value to the enterprise.
The final problem is how to locate the services on the network offered by the directory service. The Active Directory uses Domain Name System or DNS as the location mechanism for clients to find domain controllers on the network using service (SRV) and address (A) resource records.
DNS is used to provide hostname-to-IP address mapping in a similar way to how WINS was used to map NetBIOS names to IP addresses. Unlike WINS, however, DNS is not dynamic in nature and records have to be manually created, but more on that later.
Everywhere you look DNS is in use; nearly every advertisement has a web address, for example www.savilltech.com. This is a DNS name and is broken down into various parts but the result is an IP address with which your TCP/IP client can communicate.
The com part of the name is the top-level domain, which is a service provided by a number of Internet DNS services. The savilltech component is a second-level domain registered to a company that would be hosted by DNS servers within the company (or by the company's Internet Service Provider). The www is the actual host part of the name and would be the record looked up on the savilltech.com DNS server. This would resolve to one or more IP addresses.
This figure shows the overall structure of DNS. At the top is the root of the Internet, which is noted as a period (.). Under this are the top-level domains such as com, net, org, etc. These are all managed by the Internet root servers. Companies can then register second-level domain names, such as savilltech under a specific top-level domain to give savilltech.com. The company savilltech would have its own DNS server containing all records in its organization (for example a www record for its web server), which in many cases would be a record known as an alias, which simply points to the actual machine offering the web service. It is not ideal to actually have a machine called www. You might want to move the service to another server or load balance it over multiple servers.
Since DNS is used as the locator service, a mechanism is needed to advertise services and the standard types of record supported by DNS were not suitable. Therefore a new type of record, the service record (SRV record), was created. The service record is now a standard for DNS and is defined in RFC 2782. However, not all DNS implementations support it and service records are a mandatory requirement for the Active Directory. Without service records, Active Directory will not function.
Once you install an Active Directory domain you will see a large number of records added to DNS, which are service records and basically provide the clients on the network with a way to find the domain controllers by searching for LDAP service records (although the actual records are of the form _ldap._tcp.<domain name> ).
The lines that follow show the DNS records added when creating a domain. These values are stored in the netlogon.dns file created when a domain controller is promoted. This file is also dynamically re-created at the default refresh period (24 hours), or each time the Netlogon service is restarted, or when the domain controller is restarted. This data is dynamically (or manually) registered into DNS when using a Microsoft DNS server or a version of DNS, such as BIND, that supports SRV records. Ideally, of course, the idea is to use a server that supports dynamic updates. It is better than attempting to manually create all these records in DNS:
savilltech.com. 600 IN A 10.0.0.1
gc._msdcs.savilltech.com. 600 IN A 10.0.0.1
DomainDnsZones.savilltech.com. 600 IN A 10.0.0.1
ForestDnsZones.savilltech.com. 600 IN A 10.0.0.1
_ldap._tcp.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com.
_ldap._tcp.Gotham._sites.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com.
_ldap._tcp.pdc._msdcs.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com.
_ldap._tcp.gc._msdcs.savilltech.com. 600 IN SRV 0 100 3268 omega.savilltech.com.
_ldap._tcp.Gotham._sites.gc._msdcs.savilltech.com. 600 IN SRV 0 100 3268 omega.savilltech.com.
_ldap._tcp.1e95687b-3e01-44f9-adb3-70e1602237e3.domains._msdcs.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com.
1ea880a3-5df2-44b2-8229-a1cbf3d3d709._msdcs.savilltech.com. 600 IN CNAME omega.savilltech.com.
_kerberos._tcp.dc._msdcs.savilltech.com. 600 IN SRV 0 100 88 omega.savilltech.com.
_kerberos._tcp.Gotham._sites.dc._msdcs.savilltech.com. 600 IN SRV 0 100 88 omega.savilltech.com.
_ldap._tcp.dc._msdcs.savilltech.com. 600 IN SRV 0 100 389
omega.savilltech.com.
_ldap._tcp.Gotham._sites.dc._msdcs.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com.
_kerberos._tcp.savilltech.com. 600 IN SRV 0 100 88 omega.savilltech.com. _kerberos._tcp.Gotham._sites.savilltech.com. 600 IN SRV 0 100 88 omega.savilltech.com.
_gc._tcp.savilltech.com. 600 IN SRV 0 100 3268 omega.savilltech.com.
_gc._tcp.Gotham._sites.savilltech.com. 600 IN SRV 0 100 3268 omega.savilltech.com.
_kerberos._udp.savilltech.com. 600 IN SRV 0 100 88 omega.savilltech.com.
_kpasswd._tcp.savilltech.com. 600 IN SRV 0 100 464 omega.savilltech.com.
_kpasswd._udp.savilltech.com. 600 IN SRV 0 100 464 omega.savilltech.com.
_ldap._tcp.DomainDnsZones.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com. _ldap._tcp.Gotham._sites.DomainDnsZones.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com. _ldap._tcp.ForestDnsZones.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com. _ldap._tcp.Gotham._sites.ForestDnsZones.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com. _ldap._tcp.Smallville._sites.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com. _ldap._tcp.Smallville._sites.gc._msdcs.savilltech.com. 600 IN SRV 0 100 3268 omega.savilltech.com. _kerberos._tcp.Smallville._sites.dc._msdcs.savilltech.com. 600 IN SRV 0 100 88 omega.savilltech.com. _ldap._tcp.Smallville._sites.dc._msdcs.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com. _kerberos._tcp.Smallville._sites.savilltech.com. 600 IN SRV 0 100 88 omega.savilltech.com. _gc._tcp.Smallville._sites.savilltech.com. 600 IN SRV 0 100 3268 omega.savilltech.com. _ldap._tcp.Smallville._sites.DomainDnsZones.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com. _ldap._tcp.Smallville._sites.ForestDnsZones.savilltech.com. 600 IN SRV 0 100 389 omega.savilltech.com.
We discussed that DNS was static and would have to be manually updated but after installing Active Directory, you will see a large number of additions. This would seem to be a contradiction. The next requirement of DNS by the Active Directory is dynamic update.
There was a whole page of records added for our domain; manually creating all of these would be a daunting task and for the most part every domain controller would have that amount of records again. In order to aid in the management and cut down on the number of human errors, DNS has been improved to allow DNS clients to register their own records. In this case, domain controllers should be allowed to register all the records (including service records) required for clients to "find" the offered services on the network. Dynamic DNS is another standard and is defined in RFC 2136.
Unlike mandatory service records, dynamic update is not a "must-have" but rather a "really useful to have and mandatory unless you have a brain the size of a planet". It is possible to manually create all of the records required; however, it is highly recommended to use a Windows 2003 DNS server for the DNS namespaces related to the Active Directory.
Next: The Blueprint of the Active Directory >>
More IIS Articles
More By PACKT Publishing
|
 This article is taken from chapter one of the book Windows Server 2003 Active Directory Design and Implementation: Creating, Migrating, and Merging Networks by John Savill (PACKT Publishing, 2005; ISBN: 1904811086). Check it out at your favorite bookstore. Buy this book now.
|
|
