Agenda

1. AD user management
2. AD database maintenance
3. AD replication
4. DNS
5. DHCP
6. Kerberos authentication
7. Delegation Of control
8. Group Policy Management
9. Trust Relationship
10. Checklist parameters to check AD health
AD user management
Some attributes are stored in the directory, such as cn, nTSecurityDescriptor, objectGUID, and so on, and replicated to all domain controllers within a domain. A subset of these attributes
is also replicated to t
he global catalog.

Non-replicated attributes are stored on each domain controller, but are not replicated elsewhere, such as badPwdCount, lastLogon, lastLogoff, and so on. The non-replicated attributes
are attributes that pertain to a particular domain controller. For example, last Logon is the last date and time that the user network logon was validated by the particular domain
controller that is returning the property.
A user object also has constructed attributes that are not stored in the directory, but are calculated by the domain controller, such as canonicalName, distinguishedName, 
allowedAttributes, and so on.
Attributes for user objects are classified as:
Base Object Attributes
This category includes attributes required for all directory objects, such as objectClass, nTSecurityDescriptor, and so on.
Naming Attributes
This category includes attributes used to refer to or identify the object, such as distinguishedName, objectGUID, objectSID, and so on. For more information about naming attributes for
user objects, see User Naming Attributes.
Security Attributes
This category includes attributes for logon and access control. For more information about security attributes for user objects, see User Security Attributes.
Address Book Attributes
This category includes attributes for email and user data. For more information about address book attributes for user objects, see User Address Book Attributes.
Application Specific Attributes
This category includes user-specific configuration data for specific applications.
For more information about reading and modifying attributes for a user object, see Reading and Writing Attributes of Objects in Active Directory Domain Services.
For more information about the User class, including a complete list of the mayContain and mustContain attributes of the class, see User.
AD database maintenance
• Active Directory stores its data in a file named ntds.dit. The choice of filename was  taken from the fact that active
directory was initially known as NT Directory Service. By default, this file is located in the %systemroot%\NTDS folder. In
addition to using the database file, Active Directory uses log files that store information prior to committing it to the
database. The ntds.dit file is essentially a database based on X.500 standard which is hierarchical in nature. Lightweight
Directory Access Protocol (LDAP) is a protocol which is used to access the data contained in database file.
Syantax: CN=Sean,OU=Users,DC= ABC,DC=com
Where:
CN = Container Name
OU = Organizational Unit
DC = Domain Component
AD database maintenance
The database file is self-maintained for the most part, but there are a few reasons like low disk space or hardware failure that
you may need to maintain the database.
In day-to-day operation, objects will get deleted from Active Directory on a somewhat regular basis. As your Active Directory
environment grows, the database grows as needed. The reverse is not true, however. As you delete objects from Active
Directory, the database will not automatically shrink itself. This process creates “white space” (or unused space) in your
database.
Think of it like this: you have a row of soda cans on a table. If you have a row of 20 cans of soda in a single-file line, and you
put another anywhere in the line, the line grows. If you take a few cans out of the middle, the line is still just as long as it was
before, but now you have some empty spaces in there. You can add cans back to the empty space (or white space).
The same happens with active directory database. On a regular basis, Active Directory will defragment the database to
reorganize the data. This is done through the Garbage Collection Agent. The garbage-collection process runs every 12 hours
and will online defragment the white space to help with performance, but it does not do anything for the unused space that
could be returned to the disk partition where the database resides. Performing an online defragmentation, enhances your
performance, but you do not actually reclaim any drive space. To reclaim the unused white space, you must perform an
offline defragmentation.
Defragmenting the Active Directory
Database
You may experience a great amount of white space if you performed a bulk deletion or if the size of your
system-state backup is significantly increased because of the white space. Often, removing the Global
Catalogue role from a domain controller will result in large amounts of white space.
You can determine how much space is recoverable by changing the logging level of the Garbage
Collection Agent. Two levels of logging are available:
0 — Only critical events or error events are logged in the directory service log.
1 — High-level events are logged. Event ID 700 is recorded when defragmentation begins, and event ID
701 is recorded when defragmentation ends. Event ID 1646 reports the amount of free space (white
space) in the database and the total amount of allocated space.
If you find from this process that you can recover a significant amount of space, you may want to perform
an offline defragmentation of the Active Directory database file
Performing an Offline Defragmentation
• Copy the complete NTDS folder from C:\Windows\ to some safe
location. This is just a backup if anything goes wrong, we can restore
it back.
• At the command prompt, type ntdsutil and press Enter.
• At ntdsutil: prompt, type activate instance ntds and press Enter.
• At the ntdsutil: prompt, type files and press Enter.
• At the file maintenance: prompt, type compact to drive:\path,
where drive:\path is the path to a location on the local computer or
remote computer — for example D:\NTDS. If you want to compact
the database to remote folder, you can map the network drive
using net use drive: \\server\share
/user:domain\username command, where drive: is the drive letter
you would like to use for the mapping, server is the remote server
name, share is the name of the shared folder, domain is the name
of your domain, and username is the name of a user who has rights
to that folder
AD replication
Connection object:
A connection object is an Active Directory object that represents a replication connection from a source domain controller to a
destination domain controller. A domain controller is a member of a single site and is represented in the site by a server object
in Active Directory Domain Services (AD DS). Each server object has a child NTDS Settings object that represents the replicating
domain controller in the site.
KCC(Knowledge Consistency Checker):
The KCC is a built-in process that runs on all domain controllers and generates replication topology for the Active Directory forest. The
KCC creates separate replication topologies depending on whether replication is occurring within a site (intra site) or between sites
(inter site). The KCC also dynamically adjusts the topology to accommodate the addition of new domain controllers, the removal of
existing domain controllers, the movement of domain controllers to and from sites, changing costs and schedules, and domain
controllers that are temporarily unavailable or in an error state.
Failover functionality:
Sites ensure that replication is routed around network failures and offline domain controllers. The KCC runs at specified intervals to
adjust the replication topology for changes that occur in AD DS, such as when new domain controllers are added and new sites are
created. The KCC reviews the replication status of existing connections to determine if any connections are not working. If a connection
is not working due to a failed domain controller, the KCC automatically builds temporary connections to other replication partners (if
available) to ensure that replication occurs. If all the domain controllers in a site are unavailable, the KCC automatically creates
replication connections between domain controllers from another site.
AD replication
Subnet:
A subnet is a segment of a TCP/IP network to which a set of logical IP addresses are assigned. Subnets group computers in a
way that identifies their physical proximity on the network. Subnet objects in AD DS identify the network addresses that are
used to map computers to sites.
Site:
Sites are Active Directory objects that represent one or more TCP/IP subnets with highly reliable and fast network
connections. Site information allows administrators to configure Active Directory access and replication to optimize usage of
the physical network. Site objects are associated with a set of subnets, and each domain controller in a forest is associated
with an Active Directory site according to its IP address. Sites can host domain controllers from more than one domain, and a
domain can be represented in more than one site.
Site link:
Site links are Active Directory objects that represent logical paths that the KCC uses to establish a connection for Active
Directory replication. A site link object represents a set of sites that can communicate at uniform cost through a specified
inter site transport
DNS(Domain Name System)
Domain Name System (DNS) servers running on domain controllers can store their zones in Active Directory Domain Services
(AD DS). In this way, it is not necessary to configure a separate DNS replication topology that uses ordinary DNS zone transfers
because all zone data is replicated automatically by means of Active Directory replication. This simplifies the process of
deploying DNS and provides the following advantages:
Multiple masters are created for DNS replication. Therefore, any domain controller in the domain running the DNS Server
service can write updates to the Active Directory-integrated DNS zones for the domain name for which they are authoritative.
A separate DNS zone transfer topology is not needed.
Secure dynamic updates are supported. Secure dynamic updates allow an administrator to control what computers update
what names and prevent unauthorized computers from overwriting existing names in DNS.
Active Directory-integrated DNS in Windows Server 2008 stores zone data in application directory partitions. (There are no
behavioral changes from Windows Server 2003-based DNS integration with Active Directory.) The following DNS-specific
application directory partitions are created during AD DS installation:
A forest-wide application directory partition, called ForestDnsZones
Domain-wide application directory partitions for each domain in the forest, named DomainDnsZones
DHCP(Dynamic Host Configuration
Protocol)
The Dynamic Host Configuration Protocol (DHCP) allows a client to receive an IP address automatically from the
DHCP server. This process avoids configuration errors caused by configuring each computer manually. DHCP helps
prevent address conflicts that occur when an identical IP address is reused to configure a new computer on the
network. In the case of users with portable computers who change locations frequently (and subsequently need
updated client configurations), the DHCP lease renewal process helps ensure efficient and automatic updates.
Active Directory requires a DHCP server to be authorized before it can respond to client requests. If you happened
to upgrade a Windows NT 4.0 DHCP server to a Windows 2000 domain controller, and the server's DHCP service
isn't working, make sure the server is authorized.
To authorize the DHCP server for Active Directory, perform the following steps:
Select Start, Programs, Administrative Tools, DHCP.
In the console, right-click DHCP and select Manage Authorize Servers.
Click Authorize in the Manage Authorized Servers window.
Enter the name or IP address of the DHCP server to be authorized, and click OK.
To enable DHCP, a client must have the Obtain an IP Address Automatically radio button selected in the TCP/IP
Properties property sheet
Kerberos authentication
When you sit down at your workstation and press Ctrl+Alt+Del to log on and enter your credentials, your machine begins
the process of authentication. At this step, the first thing that happens is your machine sends an AS_REQ or Authentication
Service Request Kerberos message to the DC. In Kerberos, we call the DC a Key Distribution Center (KDC). Figure 1 shows the
critical contents of such a request.
The client name is either the user’s user principal name (UPN) or the user’s legacy username (sAMAccountName).
The service name in this case is always the same, a request to the krbtgt service in the user’s domain (or realm in
Kerberos parlance). To prevent replay attacks whereby an attacker recycles an AS_REQ message, the current time is
encrypted using a hash of the user’s password. This is where the five-minute clock skew tolerance most AD
administrators are familiar with comes into play. If the encrypted timestamp isn’t within five minutes of the current
time, the request is rejected.
When the KDC receives an AS_REQ message, the first thing it tries to do is decrypt the encrypted timestamp using its local
copy of the user’s password hash. If this operation fails, then an error is returned to the client and the request doesn’t
proceed any further. If the decryption is successful and the timestamp is within acceptable limits, the KDC returns an AS_REP
(Authentication Service Reply) message to the user, with an embedded message. At this point, the user’s machine caches the
TGT and session key for the lifetime of the TGT and disposes of the user’s password. By default, TGTs issued by AD KDCs
expire after ten hours.
Delegation Of control
delegate control in Active Directory Users and Computers. In Organizations, delegate control is given to the help-desk
representative to perform the tasks of reset password, add computer or server in domain, create new user, etc. In a  domain,
domain administrator is a user who can perform all operations and tasks related to domain and Active Directory. Domain
Administrator is a member of Domain Admins group and also a user who is not available 24 x 7 x 365. So, the question is
when the domain administrator is not available then who will manage the Active Directory.
First option is that, we will add any other user into the Domain Admins group. This would assign Domain Admin permissions
to the newly added user, these rights are sufficient to perform any domain level change in the environment. But do you really
want to give keys of kingdom to anyone? In my opinion, this is not the right way of delegating control.
There is an another option of Delegate Control using Active Directory Users and Computers, through which we can deploy
customized access and permissions for the domain users. Through this, users can perform the tasks that Administrator is
designated to perform.
Group Policy Management
Group Policy in Active Directory (AD) helps IT administrators quickly manage AD users, computers, and groups. Traditionally,
administrators had to rely on Group Policy management tools such as the Group Policy Management Console (GPMC) and
Active Directory Users and Computers (ADUC) for Active Directory and group policy management. Managing Group Policy
using just the native AD group policy management tools and PowerShell can be mundane and time-consuming.
Manage every aspect of Windows Active Directory Group Policy:
• Create a GPO and link it to any container at once
• Enable or disable GPOs or individual configuration settings (user/computer configurations)
• Delete GPOs in bulk
• Create GPO links
• Enable or disable or remove GPO links
• Enforce GPOs or remove their enforcement
• Block or unblock GPO inheritance for any domain or organizational unit (OU) in bulk
Trust Relationship
Prospects of globalization and international commerce have increased the possibility of companies operating multiforest
network enterprise structures. Before we look at the intricacies of interforest trusts, we briefly review trust relationships as
they exist within a single forest.
Before we look at the intricacies of Windows 2000 and interforest trusts, we will briefly review trust relationships as they
existed within NT 4.0. Those of you who are upgrading from Windows NT 4.0 will be familiar with the trust relationships used
to allow users in one domain to access resources in another domain. Basically, you could configure one domain to trust
another one so that users in the second domain could access resources in the first one. Windows NT 4.0 did not create any
trust relationships by itself; administrators in both the trusting and trusted domains had to configure every trust relationship.
The domain where the resources are located is referred to as the trusting or resourcedomain, and the domain where the
accounts are kept is referred to as the trusted or accounts domain.
Some characteristics of trust relationships in Windows NT 4.0 follow:
In a one-way trust relationship, the trusting domain makes its resources available to the trusted domain (see Figure 3.1). With
the appropriate permissions, a user from the trusted domain can access resources on the trusting domain. However, users in
the trusting domain are unable to access resources in the trusted domain, unless a two-way trust is set up.
Trust Relationship
A trust relationship exists between only two domains. Each trust relationship has just one trusting domain and just one trusted
domain.
A two-way trust relationship between domains is simply the existence of two one-way trusts in opposite directions between the
domains.
In Windows NT 4.0, trust relationships were not transitive; that is, if Domain A trusts Domain B and Domain B trusts Domain C,
these relationships do not mean that Domain A automatically trusts Domain C. To have such a relationship, a third trust
relationship must be set up whereby Domain A trusts Domain C
•External trusts These one-way trusts are individual trust relationships set up between two domains in different forests, as can be
done in Windows 2000. The forests involved may be operating at any forest functional level. You can use this type of trust if you
need to enable resource sharing only between specific domains in different forests. You can also use this type of trust relationship
between an Active Directory domain and a Windows NT 4.0 domain.
•Forest trusts As already mentioned, these trusts include complete trust relationships between all domains in the relevant forests,
thereby enabling resource sharing among all domains in the forests. The trust relationship can be either one-way or two-way.
Both forests must be operating at the Windows Server 2003 forest functional level. The use of forest trusts offers several benefits:
•They simplify resource management between forests by reducing the number of external trusts needed for resource sharing.
•They provide a wider scope of UPN authentications, which can be used across the trusting forests.
•They provide increased administrative flexibility by enabling administrators to split collaborative delegation efforts with
administrators in other forests.
•Directory replication is isolated within each forest. Forestwide configuration modifications such as adding new domains or
modifying the schema affect only the forest to which they apply, and not trusting forests.
•They provide greater trustworthiness of authorization data. Administrators can use both the Kerberos and NTLM authentication
protocols when authorization data is transferred between forests.
•Realm trusts These are one-way nontransitive trusts that you can set up between an Active Directory domain and a Kerberos V5
realm such as found in Unix and MIT implementations.
Checklist parameters to check AD health
• The key aspects that help support and maintain AD include the following:
• DNS
• Checking zones and removing obsolete zonesThe cleanup and removal of stale zones and resource records is
required to prevent its accumulation in zone data and improve responsiveness.
• Checking name servers and removing WINS dependencies Active Directory is DNS intensive and WINS dependencies
can be removed.
• Checking DNS for dormant static records and configuring DNS scavenging DNS scavenging removes stale and
orphaned DNS records from the database.
• Clearing DNS cache Clearing all entries from the DNS forwarding cache helps in updating new DNS information. 
• Updating root hints Root hints configure authoritative servers of non-root zones to discover other authoritative
servers that exist in other subtrees or higher levels.
• Allowing only secure dynamic updates for all DNS zones Ensures that only authenticated users can submit DNS
updates using a secure method that prevents IP addresses from being hijacked.
• Securing DNS Server It secures access control of the DNS Server service.
Checklist parameters to check AD health
• AD Replication
• Checking if replication is working properly and within acceptable limits Replication is critical to the availability and
consistency of data across domain controllers. If replication fails between DCs several aspects of AD would become
unavailable.
• Verifying if all DCs are communicating with the central monitoring console and examining all replication alerts on DCs
Examining and resolving alerts regularly can avoid service outages to some extent. A communication failure between
the DC and the monitoring infrastructure creates problems in receiving these alerts.
• Verifying that all DCs are running with the same service pack and hot fix patchesIf DCs run with different versions of
software, it may cause problems.
• Reviewing trust relationships in the forest and removing broken trusts Communication and authentication between
domains or forests require trusts. Any broken or stale trust relationship between domains should be removed.
• AD Backups
• Capturing system state information related to the AD database, logs, registry, boot files, SYSVOL and other system files
Regular backups help in restoring the most recent information in AD.
• DHCP
• Checking logs and monitoring real-time data Checking logs identifies critical DHCP related events. It is recommended to
implement a proactive monitoring solution for real-time data.