The Importance of a Domain - The Blueprint of the Active Directory (Page 6 of 11 )
Active Directory needs to have far greater scope of attributes than available under NT 4 domains because it is a directory service designed to hold information about all parts of your organization. However, it is impossible to create all possible required fields; what is needed is some kind of plan for the information that can exist in the Active Directory implementation that can be modified if needed.
What the Active Directory schema provides is a definition of the objects (or classes) available and the attributes the objects have. These attributes are defined separately from the objects and then linked to the object definitions, allowing objects to be defined using any attribute described in the schema.
What is vital with the schema is it can be dynamically extended, defining new classes and attributes or adding new attributes to existing classes. Modifying the schema is not to be taken lightly and has effects on replication throughout the entire organization. Nevertheless, it is a very useful ability.
Only one domain controller in your entire organization (assuming you have one 'forest') can modify the schema. The user trying to modify the schema will need to have certain permissions; you should restrict the normal administrators' ability to change the schema; only very high-level administrators should have schema modification abilities.
Once you start installing newer backoffice applications you will start to understand how vital the schema is and how the Active Directory is the foundation of your entire infrastructure. Nearly every single major backoffice service wants to extend the schema (some more than others!). Exchange, Systems Management Server, and SharePoint are just a few of the services that extend the Active Directory schema with new attributes and classes.
Creating a Domain Controller
During the installation of Windows NT 4 Server, you were asked if the server would be a PDC, BDC, or standalone server. When you install Windows 2000/2003 Server you are no longer asked this question, so how do you create a domain controller?
This was always a major problem with NT 4 servers. Defining the server's role at installation time was a pain and this has now been resolved. Rather than defining a server's roles during installation you now run a wizard after the operating system installation is complete, to change the server to a domain controller or to change a domain controller to a normal server.
This wizard is known as DCPROMO (Domain Controller Promotion) and has a step-by-step process to guide the whole process (an example is provided in Chapter 2).
You can now technically switch a server's domain controller status (that is not to say you should perform this without planning; there are still other factors!).
One thing you will notice even with the wizard is the lack of a PDC/BDC option. Surely, you can have more than one domain controller per domain with the Active Directory.
Domain Controller Farm
There have been huge advances with the Active Directory: a single domain can hold millions of objects and the performance of domain controllers is much higher thanks to more efficient authentication protocols, but you will still want more than one domain controller for fault tolerance and load balancing reasons.
The concept of a single master domain controller has gone with the Active Directory; now multi-master replication is used, which means any domain controller can make changes to its copy of the domain information and through a process known as multi-master replication the databases on each individual domain controller are kept synchronized.
It would seem that all domain controllers are equal but some are more equal than others. Some functions do not lend themselves to multiple masters. We will talk more about these functions once we have looked at more of the domain concepts.
The replication topology varies depending on the location of the domain controllers. Replication is more frequent if the domain controllers are in the same physical location and can be highly tailored between physical locations. We will cover this in more detail later in the book.
One important factor to remember is that Windows NT 4 BDCs are still supported in Active Directory domains (but not an NT 4 PDC; if you upgrade, it has to be PDC first) and these BDCs do not support multi-master replication; they only pull updates from one domain controller—the PDC. Since this PDC no longer exists, a single Active Directory domain controller in each domain pretends it is an NT 4 PDC for the benefit of the NT 4 BDCs.
Kerberos
NTLM is an old protocol and while it still works and is effective, it has some limitations:
- It's not a very fast protocol and has quite a high overhead.
- Each client access requires the server to contact a domain controller for verification, putting load on the server.
- There is a proprietary protocol cutting down on supportability.
- No support for delegation of authentication is provided.
- Servers are not able to authenticate with other servers.
For the Active Directory, Microsoft has chosen Kerberos as its default protocol (although NTLM is still supported for backwards compatibility). Kerberos is an industry standard defined in RFC 1510 and takes its name from the three-headed dog that guarded the gates of the underworld in Greco-Roman mythology.
The three-headed part comes from the way in which Kerberos works: the client, the server the client wishes to use, and the trusted third party, which is the Key Distribution Center providing authentication. It's important to understand that it's not only users who contact the KDC for access to a server, services on servers also contact the KDC to enable access to other servers.
This figure illustrates the major steps involved in a client communicating with the KDC to get the information needed to talk to a server. The idea is: if two people know a secret they can communicate and if only they both know the secret they know the other person is who they say they are. You cannot just send the secret over the network as plain text because anyone with a network sniffer could find the "secret".
The Kerberos protocol solves this problem with secret key cryptography. Rather than sharing a password, communication partners share a cryptographic key—symmetric in nature—that can both encrypt and decrypt.
The process starts when the user first logs onto the domain. It works as follows:
- The user enters the username and password at the logon screen. The local Kerberos client converts the password to an encryption key by creating a one-way hash value.
- The local client time is then encrypted with the generated encryption key and a KRB_AS_REQ (Kerberos Authentication Service Request) is generated containing the user's name, the request for a ticket-granting ticket, and the encrypted time. This is sent to the Authentication Service component of the Key Distribution Center (KDC).
- The KDC (a domain controller having access to the Active Directory) looks up the user's information including the password hash and uses it to decrypt the time. If it is within five minutes (the time limit can be changed) of the server's time, it knows it is not a replay. Once the user is confirmed, the KDC creates a session key used for future communication between the user and the KDC. This generated session key is encrypted with the user's encryption key (the hash of the password) and also encrypted with the KDCs own long-term key, which is known as the ticket-granting ticket. This is sent back as a KRB_AS_REP (Kerberos Authentication Service Reply).
- The client now wishes to talk to a server. It sends a request to the Ticket-Granting Service component of the KDC containing the ticket-granting ticket and the server it wishes to talk to in a KRB_TGS_REQ (Kerberos Ticket-Granting Service Request).
- The KDC decrypts the KRB_TGS_REQ using the ticket-granting ticket (which it decrypts with its own secret key) and assuming it passes authentication testing, generates a session key to use for communication between the user and the desired server. This session key is encrypted with the user's encryption key and with the server's long-term key in the form of a ticket. These are then sent to the user in a KRB_TGS_REP (Kerberos Ticket-Granting Service Reply).
- Now the client can initiate communications with the server by sending a KRB_AP_REQ (Kerberos Application Request) containing the users name and the time encrypted with the session key to be used between the user and the server along with the servers ticket (which is the session key encrypted with the servers long-term key).
- The server decrypts the ticket using its long-term key and extracts the sessions key. It can then decrypt the encrypted time and if it passes, the server can trust the client's identity. If the client asked for mutual authentication, the server then encrypts the time using the session key it shares with the user and sends it back as a KRB_AP_REP (Kerberos Application Reply).
- The client at the user's workstation then decrypts the KRB_AP_REP if requested. If the authentication passes, then the client knows the server could decrypt and use the ticket, proving they are who they said they were.
- The client and the server now have a mutual session key that they can use to encrypt any required communication.
You will notice that at no time do any of the servers have to remember anything about the client. The client always sends the server a ticket generated by the KDC for its use with all client communication. The server never has to contact the KDC directly during client/server session initialization.
For each server the user needs to communicate with, a separate ticket will be created and the process of the KRB_TGS_REQ—KRB_TGS_REP—KRB_AP_REQ— KRB_AP_REP performed.
These issued tickets only last a certain amount of time and the KDC does not keep track or notify clients of their expiry, but in the case of an expired ticket or even an expired ticket-granting ticket, a new one will be requested using the discussed steps. The user's password hash is cached. However, if for some reason it is no longer cached, the user may be asked for their credentials again.
You will notice that in nearly all steps the time is encrypted with the session key to prove it is not just a replay. Since time is part of the encryption technology machines using Kerberos need to be time-synchronized with an SNTP service.
There are more steps involved if the server is in a separate domain and this will be covered in later chapters.
Next: Domains >>
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.
|
|
