COMP2017 – Server Administration
Implementing Active Directory
Objectives
Installing a New Active Directory Forest
Establishing and Maintaining Trust Relationships
Configuring Active Directory Lightweight Directory Services
Configuring a Read-Only Domain Controller
MCTS Windows Server 2008 Active Directory 2 2
Lesson 2
Installing a New Active Directory Forest
The first Active Directory domain on the network is the forest root domain
It needs to remain online and in place for the life of an AD installation
You can add and remove child domains under it – but the forest root domain must stay in place
You can create a New AD Forest by opening the Active Directory Installation Wizard using the dcpromo.exe commandline tool or from the Server Manager utility that's installed in the Administrative Tools folder
Lesson 2
Installing a New Active Directory Forest
On the Select Server Roles window, select Active Directory Domain Services
Lesson 2
Installing a New Active Directory Forest
The advantage of the Server Manager interface is that it will allow you to view other roles the server might be performing
The advantage of using dcpromo will allow you to script or automate the installation process
The first domain controller installed in a new Active Directory forest will hold the Flexible Single Master Operations (FSMO) roles, which are specific server roles that work together to enable the multimaster functionality of Active Directory
Lesson 2
Installing a New Active Directory Forest
The advantage of the Server Manager interface is that it will allow you to view other roles the server might be performing
The advantage of using dcpromo will allow you to script or automate the installation process
The first domain controller installed in a new Active Directory forest will hold the Flexible Single Master Operations (FSMO) roles, which are specific server roles that work together to enable the multimaster functionality of Active Directory
Lesson 2
Installing a New Active Directory Forest
Modifying the schema is a per Forest role because the Active Directory schema is shared among all domains in a forest
The server holding the Schema Master operations role must be accessible to all domains in the forest
After the initial domain controller creation, additional domain controllers can be installed and the roles can be transferred to the new domain controllers
See textbook chapter 2 – pgs 25 through 30 for the detailed steps in installing a new AD Forest
Lesson 2
Installing a New Active Directory Forest – Post Installation
After the Active Directory installation, you should verify a number of items before you consider it complete
You should verify several items before considering that the installation is complete and operational:
Application directory partition creation
Aging and scavenging for zones
Forward lookup zones and SRV records
Reverse lookup zones
Lesson 2
Creating a Directory Partition
Application directory partitions are used to separate forest-wide DNS information from domain-wide DNS information to control the scope of replication
Information in an application partition can be configured to replicate to any domain controller in the forest, even if they are not all in the same domain
This allows you to control which DNS data is replicated within a single domain or throughout the entire forest
Lesson 2
Creating a Directory Partition
The following points are key to understanding application directory partitions:
Application directory partitions are automatically created when installing Active Directory Integrated DNS
You must be a member of the Enterprise Admins group to create or modify an application directory partition
If you were unable to create an application directory partition during the AD Installation Wizard, you can do so manually at a later time
Lesson 2
Configuring Aging and Scavenging
Aging and scavenging (not configured by default) are processes that can be used by Windows Server 2008 DNS to clean up the DNS database after DNS records become "stale" or out of date
Without this process, the DNS database would require manual maintenance to prevent performance degradation and wasted disk-space
See details on how to configure aging and scavenging on pages 32-33
Lesson 2
Verifying the Creation of a Forward Lookup Zone
Forward lookup zones are necessary for computer hostname-to—IP address mappings, which are used for name resolution by a variety of services
For example, when a user requests access to a server based on its host name, the request is passed to a DNS server to resolve the host name to an IP address
Most queries are based on forward lookups
See pages 33 – 34 for how to verify the creation of a forward lookup zone and records
Lesson 2
Verifying Dynamic Updates
For domain controllers to register their records with DNS at startup, dynamic updates must be allowed
By default, when a DNS zone is Active Directory integrated, Secure Dynamic Updates are enabled. This means, a client must be authenticated before attempting to update or add information to the DNS database
This prevents unwanted or unnecessary records from being added to the database, avoiding performance, space, and potential security issues
Lesson 2
Creating a Reverse Lookup Zone
In addition to forward lookup zones, which are automatically created by the Active Directory Installation Wizard, you should also configure a reverse lookup zone for full DNS functionality
Reverse lookup zones answer queries in which a client provides an IP address and DNS resolves the IP address to a host name
It is good practice to add reverse lookup zones for troubleshooting, security checks, and reverse IP queries
See pages 35 – 36 for detailed how-to steps
Lesson 2
Raising the Domain and Forest Functional Levels
To leverage more advanced features in Active Directory, you can raise the domain and forest functional levels
Domain and forest functional levels are available to provide backward compatibility with previous Windows Server operating systems
Prior to raising the domain functional levels, you must verify that any previous Microsoft Windows network operating systems are NOT needed in the domain
See steps on pages 37 - 38
Lesson 2
Raising the Domain and Forest Functional Levels
The following are key facts and requirements for raising domain and forest functional levels:
This is a one-way operation. Raising the domain and forest functional levels cannot be reversed without a complete reinstallation of the domain or forest
Each domain can be handled independently, allowing a phased approach
The forest functional level cannot be raised until all domains in a forest have been raised to the corresponding Domain Functional Level
You must be logged on as a member of the Domain Admins group to raise the domain functional level
You must be logged on as a member of the Enterprise Admins group to raise the forest functional level
Lesson 2
Adding a Second Domain Controller to the Forest Root
A second domain controller should be added to each domain for fault tolerance
This provides some redundancy in case one of the domain controllers fails
Also, because the first domain controller in the forest holds all FSMO roles, adding a second domain controller allows you to offload some of the work to another domain controller
See pages 38 – 39 for detailed steps
Lesson 2
Installing Active Directory on Server Core
A new feature of Windows Server 2008 is Server Core which creates a minimal environment for running only specific services and roles and runs almost entirely without a graphical user interface (command mode)
Server Core provides a useful way to deploy a domain controller with an extremely small security footprint, improving the security of domain controllers in branch offices or other remote environments
Because there are no graphical wizards - you will need to run dcpromo from the command line using an unattended installation, which uses a specially formatted text file to specify the necessary installation options
See page 40 for details
Lesson 2
Removing Active Directory
Removing Active Directory from a domain controller demotes that computer to a member server within an Active Directory domain
You will use this to decommission older hardware or to remove Active Directory so that you can perform troubleshooting or extensive maintenance on that server
See page 41 for the procedure
Lesson 2
Working with Read-Only Domain Controllers
Another new feature of Windows Server 2008 is the Read-Only Domain Controller (RODC)
Can be used to greatly improve the security of a domain controller that's deployed in a branch office or another hard-to-secure location
Read-Only Domain Controllers allow you to deploy a domain controller that will host a read-only copy of the Active Directory database. This means that an administrator will need to connect to a writeable domain controller to make any changes to Active Directory
Lesson 2
Working with Read-Only Domain Controllers
RODCs do not perform any outbound replication - They only accept inbound replication connections from writeable domain controllers
You need to have at least one writeable Windows Server 2008 domain controller deployed in your environment, and you need to be at the Windows Server 2003 domain and forest functional levels
Each RODC can be configured with its own Password Replication Policy - you can specify a particular list of user or group accounts whose password information should be stored (or cached) on a particular RODC - you can also configure specific users or groups whose password information should not be cached on an RODC
See pages 43 - 47
Lesson 2
Modifying the Active Directory Schema
Many applications, such as email, will require modification to add necessary objects to the Active Directory database – a key task for any Active Directory administrator
Exchange, for example, adds over 1000 classes and attributes
The Active Directory schema is replicated to every domain controller within a forest, which means that each Active Directory forest can only have a single schema – managed by domain controller that is assigned the Schema Master FSMO role (first domain controller installed in the forest)
Lesson 2
Modifying the Active Directory Schema
Schema extensions are replicated to all domain controllers in the forest and have a global effect on the modified objects and attributes.
Default system classes cannot be modified, but additional classes can be added and changed
Any class and attribute that you add to the schema cannot be removed; extending the schema is a one-way operation. However, beginning in Windows Server 2003, schema additions can be deactivated
When the schema is modified, it triggers replication within the forest. Planning modification of the schema may require sensitivity to the time of day and the possible performance impact
A certain amount of latency can be expected before all domain controllers contain consistent schema information
Lesson 2
Configuring Active Directory Lightweight Directory Services
Server 2008 includes a new Active Directory Lightweight Directory Services (AD LDS) role that provides developers the ability to store data for directory-enabled applications without incurring the overhead of extending the Active Directory schema
Each AD LDS instance has its own schema, which allows developers to create, deploy, and upgrade directory-enabled applications without worrying about the one-way nature of Active Directory schema modifications
See pages 50 – 52 on how to configure AD LDS
Lesson 2
Establishing and Maintaining Trust Relationships
Trust relationships exist to make resource accessibility easier between domains and forests
In addition to the default trust relationships that exist between parent and child domains and between root domains of domain trees within a forest, four trust types can be manually established in Windows Server 2008
Lesson 2
Establishing and Maintaining Trust Relationships
Shortcut trusts - used to shorten the"tree-walking" process for users who require frequent access to resources elsewhere in the forest
Cross-forest trusts - allows you to create two-way transitive trusts between separate forests.
External trusts - used to configure a one-way nontransitive trust with a Windows 2000 domain or a single domain in an external organization
Realm trusts - allow you to configure trust relationships between Windows Server 2008 Active Directory and a UNIX MIT Kerberos realm, which is the UNIX equivalent to an Active Directory domain allowing centralized user and password administration on a UNIX network
Lesson 2
Creating a Trust Relationship
Use the Active Directory Domains and Trusts MMC snap-in to establish manual trust relationships
If you have the appropriate administrative privileges in the source and target forest or domain, you can create both sides of the trust relationship
To create a cross-forest trust, each forest must be able to resolve the DNS names and SRV records contained in the other forest through the use of secondary zones, stub zones, or conditional forwarding
Lesson 2
Verifying a Trust Relationship
After you establish a manual trust, you can verify the trust using either Active Directory Domains and Trusts or the netdom command-line tool
Because automatic trusts are part of the default functionality provided by Active Directory, you can only use this process to verify shortcut, external, and cross-forest trusts
Lesson 2
Revoking a Trust Relationship
In some cases, it may be necessary to remove an established trust
For example, if a corporation relinquishes its business relationship with a supplier that was trusted, you will need to revoke the trust to prevent unwanted access to network resources
You can use Active Directory Domains and Trusts or netdom to revoke a trust
Lesson 2
Changing the Default Suffix for User Principal Names
As an organization grows due to expansion, acquisitions, mergers, and new locations, the Active Directory structure can become difficult to navigate
Users needing access to more than one tree structure within the forest can find it cumbersome to recall what is contained in each domain
To alleviate this confusion and provide a simple means for users to gain global access to the forest structure, Active Directory supports User Principal Names
Lesson 2
Changing the Default Suffix for User Principal Names
A User Principal Name (UPN) is stored in the global catalog, which allows UPNs to be available forest-wide
A UPN follows a naming convention that can reflect the forest root domain or another alias that you configure that follows the format of username@domainname
Common practice is to configure the UPN to match the email ID of the user
In larger organizations, this may mean that you will need to modify the default UPN suffix when creating users
Lesson 2
Changing the Default Suffix for User Principal Names
To modify the default suffix for a UPN, you must have Enterprise Administrator credentials because this is a forest-wide operation
Lesson 2
Summary
Active Directory requires DNS to be installed. DNS does not have to be installed on a Windows Server 2008 machine, but the version of DNS used does need to support SRV records for Active Directory to function.
Planning the forest and domain structure should include a checklist that can be referenced for dialog information required by the Active Directory Installation Wizard.
Verification of a solid Active Directory installation includes verifying DNS zones and the creation of SRV records. Additional items, such as reverse lookups, aging, and scavenging, also should be configured.
Lesson 2
Summary
Application directory partitions are automatically created when Active Directory integrated zones are configured in DNS. These partitions allow replica placement within the forest structure.
System classes of the schema cannot be modified, but additional classes can be added. Classes and attributes cannot be deleted, but they can be deactivated.
Planning forest and domain functionality is dependent on the need for down-level operating system compatibility. Raising a forest or domain functional level is a procedure that cannot be reversed.
Lesson 2
Summary
Four types of manual trusts can be created: shortcut, external, cross-forest, and realm trusts. Manual trusts can be created by using Active Directory Domains and Trusts or netdom at a command line.
UPNs provide a mechanism to make access to resources in multiple domains user friendly. UPNs follow a naming format similar to email addresses. You must be a member of the Enterprise Admins group to add additional suffixes that can be assigned at user object creation.