Sie sind auf Seite 1von 16

Active Directory 2008 R2

Advanced Features

Key Features

•Active Directory Recycle Bin •Managed Service Accounts •Fine-Grained Password Policies • Read-Only Domain Controllers • Active Directory Administrative Center

Recycle Bin for AD

• Past limitations –Accidental deletions are the number #1 cause of AD Disaster \ Recovery scenarios •Feature takeaways –Allows recovery of deleted users, groups, etc •Locate deleted object:

Get-ADObject–Filter {} -IncludeDeletedObjects •Recover deleted object:

Restore-ADObject-Identity {id} –All attributes are automatically restored •Including well known & problematic ‘Linked Attributes’ •Description, password, group membership, managed by, etc

Enabling Recycle Bin Feature

Object “State” considerations Objects deleted before enabling the Recycle bin (i.e. in a Tombstoned state) will be in a “Recycled” state once the Recycle bin is enabled. These Objects cannot be recovered using “Undelete” functionality


These objects can only be recovered using an Authoritative restore of a backup taken “before” the recycle bin was enabled

Take System state backups before enabling the Recycle Bin Feature. Avoid deletions between backup and enabling Recycle Bin.

Enabling Recycle Bin – Powershell

Raising Functional Level:

Set-ADForestMode –Identity -ForestMode Windows2008R2Forest

Enabling Recycle Bin:

Enable-ADOptionalFeature –Identity "Recycle Bin Feature" –Scope ForestOrConfigurationSet –Target “"

“Recycle Bin Feature” object:

CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=WindowsNT,CN=Services,CN=Configuration…

“Scope” parameter:

ForestOrConfigurationSet - “CN=partitions,CN=Configuration….”

Managed Service Accounts

Past limitations


Running multiple services under Built in accounts does not provide service isolation

Running services under user account requires cumbersome password management

Feature takeaways


Managed Service Accounts provide the isolation that services need along with automatic password management

Lowers TCO through reduced service outages (for manual password resets and related issues)

TCO -Total cost of ownership Use one Managed Service Account per Service per Server



Service account cannot be shared by multiple machines.


Does not support failover clustering or NLB – we’ve heard the feedback


Can automatically update SPNs (SPN management requires 2008 R2 FFL )

The concept of MSA’s

Traditionally, Windows Service accounts can run under:



Built-in accounts (local service, network service or local system)


Local accounts.


Domain accounts.

When services are configured to run under domain accounts, administrators have to Perform the following tasks:



Configure the services to run under the service account.


Assign to

the service

account the SPN

needed for authenticating to the


service application.



Regularly change the password of the service account to maintain security or


degrade security by setting the password to never expire


Reflect the password change in the service configuration to update the LSA secrets of the member.


These tasks can take a considerable amount of time to the administrator and are error prone which could lead to important outages.

Windows Server 2008 R2 addresses this problem by providing a new Managed Service Account class in Active Directory: msDS-ManagedServiceAccount. Accounts created under this class provide automatic password management and simplified SPN management.

Automatic password Management

Managed Service Accounts passwords are changed when:


The machine account password changes at its regular interval (defined via GPO

“Domain Member: Maximum machine account password age” under “Computer Configuration\Windows Settings\Security Settings\Local Policies\Security


Options”. It is set to 30 days by default. The password is manually reset via:



The Nltest utility: nltest /sc_change_pwd:<domain> Primary purpose of

this is to reset computer account pwd When the MSA is installed on system

The MSA password is changed both in AD and in the LSA secrets of the member by the Netlogon scavenger on the member. No action is required from the administrator.



Note that passwords for managed service accounts are not controlled by:


The domain password policy (items of “Computer Configuration\Windows


Settings\Security Settings\Account Policies\Password Policies”). The Fine-Grained password policies.

Restrictions on MSA

• The schema must be upgraded to Windows Server 2008 R2 (version 47) to be able to use MSA. • The domain must be prepared for Windows Server 2008 R2 (adprep/domainprep) to be able to use MSA. • MSA can only be used on machines running windows 7 or Windows Server 2008


• MSA cannot be assigned to clustered services that can run on different members of the cluster. • One service account can be used for services on a single machine only. i.e. a service account cannot be shared across multiple machines. • MSA can be used in a domain with functional level set to Windows Server 2003 or Windows Server 2008 as long as or contains at least one DC running Windows Server 2008 R2 or down-level DC with AD management gateway service (due to AD PowerShell management being the only MS provided tool that calls the new APIs) • Only the automatic password management feature will be available in down-level domain.

2008 Fine-Grained Password Policy

In Windows Server 2008, we can use fine-grained password policies to specify

multiple password policies and apply different password restrictions and account lockout policies to different sets of users within a single domain To store fine-grained password policies, Windows Server 2008 includes two new object classes in the Active Directory Domain Services (AD DS) schema:


Password Settings Container, Password Settings

Applying FGPP


Fine-grained password policies apply only to user objects (or inetOrgPerson objects if they are used instead of user objects) and global security groups

Password filters


Fine-grained password policies do not interfere with custom password filters that we might use in the same domain

Non-Default Password Settings Container


In addition to the default Password Settings Container, administrators can


create their own custom PSCs under the System container. This action is not recommended because the PSOs that are held in these

custom PSC’s are not taken into consideration by the Resultant Set of Policy logic.

Requirements for Implementing FGPP’s

Domain Functional Level:


For the fine-grained password and account lockout policies to function properly in a given domain, the domain functional level of that domain must be set to Windows Server 2008.



By default, only members of the Domain Admins group can create PSOs

Permissions delegation:


We can delegate Read Property permissions on the default security descriptor of


the PSO object in the schema to any other group (such as Help desk personnel or a management application) in the domain or forest The user can read the msDS-ResultantPSO or the msDS-PSOApplied attributes, but these attributes display only the distinguished name of the PSO that applies to the user. The user cannot see the settings within that PSO.

Read-Only Active Directory Database

RODC database contains all Active Directory partitions stored on writable DCs


Some system attributes are written locally (LastLogon, LogonCount,


RODC database is updated via AD replication

LDAP write operations against RODC are not allowed

BadPwdCount, BadPwdTime, lockoutTime, LastInteractiveLogon, LastFailedInteractiveLogon and Site Affinity) LastLogonTimestamp – written locally and write is forwarded

LDAP write operations generate referrals to writable DCs


LDAP_REFERRAL operation to writable DC by name.

Password Caching

No account passwords are cached on RODC by default


Except KRBTGT_xxxxxx and the RODC machine account

Password replication policy has to be defined to allow password caching

RODC proxies authentication requests for accounts without cached passwords to a

After each authentication attempt that is serviced by an RODC, the RODC performs a

replicate single object (RSO) operation to replicate the account credentials if it does not have the current credentials stored locally. If credentials are cached on the RODC, the RODC can directly service authentication requests until credentials change


Stored in the same attributes as a writeable DC (i.e. unicodePwd)

Password Replication Policy

Managed by using ADUC and Repadmin

Two new built-in groups are introduced in Windows Server 2008 Active Directory domains to support RODC operations:




Allowed RODC Password Replication Group

Denied RODC Password Replication Group

By default, the two groups are respectively added to the msDS-Reveal-

OnDemandGroup and msDS-NeverRevealGroup Active Directory attributes Shadow groups with automated provisioning processes will help manage password replication policies the best.

Admin Role Separation

Domain users can be added to local Administrators group on RODC

Local Administrators cannot administer other domain controllers

Users / groups are added to local administrators using DSMGMT.EXE or through the managedby tab of the RODC computer account


C:\>dsmgmt Dsmgmt: Local Roles

Local roles: add <domain\user | domain\group> administrators HKLM\System\CCS\Control\LSA\RODCRoles

RODC Deployment Pre-Requisites

The forest functional level must be Windows Server 2003 or higher

The domain functional level must be Windows Server 2003 or higher

Ensure at least one writable domain controller is running Windows Server 2008 for the same domain as the RODC


This provides the RODC with a replication partner

Run the adprep /rodcprep against the doman naming FSMO



This step is required to enable RODC to replicate DNS partitions

The IM must be contacted for each application partition KB 949257

AD Administrative Center

Past limitations Non task-oriented UI causes user pain Representation in MMC not scalable for large datasets Limited to managing one domain at a time




Feature takeaway Task oriented administration model, with support for larger datasets and



progressive disclosure of data Consistency between CLI and UI capabilities


Navigation experience designed to support multi-domain, multi-forest


environments Foundation for future UI enhancements

Three migration methods are available, In-Place Upgrade (stay on the existin Transitioning (maintaining existing str Restructuring (building a new AD envi

2003 to 2008 R2
2003 to 2008 R2

In-Place Upgrade: Must be a Transition and Restructuring

The general workflows described in this section also apply to migration to Windows 2008 (R

Transitioning a Windows 2003 Domain to Windows 2008 R2 Environment:

Windows 2003 DC’s are mostly 64 bit.

(Even if we have 32bit Windows 2003 we can still use this process.)

The Windows 2003 Active Directory is healthy

All Windows 2003 Domains are in Windows 2003 Mode This is a requirement for

Windows 2008 R2. All applications / services running on the Domain Controllers are supported on

Windows 2008 R2. Research and test our applications as needed.

DNS is fault tolerant throughout the company Meaning DNS clients have primary

and secondary servers configured. DNS will be transitioned to a Windows 2008 R2 DC/DNS server

How this is done can vary, this document will assume that after installing the first

Windows 2008 R2 DC we will decommission the current DC/DNS server. Then install a second Windows 2008 R2 DC with DNS, reusing the previous IP addresses. Repeat process for all other DNS servers. All Windows 2003 DC’s will be replaced.

While this is an assumption, it need not take place in a single day, week, or month,

but it should be done as quickly as possible.

We can run a mixed of 2003 and 2008

DC indefinitely, but the benefits of 2008 are minimal until all DC’s are Windows


All hardware meets the Windows 2008 R2 requirements.

All installations / changes will take place during periods of low activity or on DC’s

with low activity. This may require transferring FSMO roles as needed.

We should perform these steps in a dedicated test environment first.

Preparing the Forest and Domains


Extend the Schema to support Win2008 R2 Domain Controllers




Copy the support\adprep directory from the Windows 2008 R2 DVD to Domain Controllers holding these respective FSMO Roles.



Schema Master (1 DC per forest)



Domain Naming Master (1 DC per forest)



Infrastructure Master (1 DC per domain)



Using the copied folder on each DC run the following commands in the order specified in the following table. Use adprep (Use adprep32 if the OS on the DC is 32bit.)




Domain Controller





adprep /forestprep


Schema and Enterprise

Schema Master

3-5 mins




adprep /rodcprep


Schema and Enterprise

Domain Naming Master





adprep /domainprep /gpprep


Domain Admin

Infrastructure Master



Check the following log file on each DC to verify there were no errors. %SystemRoot%\Debug\adprep\logs\yyyymmddhhmmss\adprep.log



If we run adprep multiple times on a DC then a new log is created for each run.


Force replication before proceeding to the next schema update.


Installing the First Windows 2008 R2 DC to Each Domain

We can install the very first Windows 2008 R2 DC to any domain in the forest. However,

take the following into account when selecting the first domain to add the DC to in the forest.


Forest Root Domain: This domain is generally preferred above all others, especially if this is an Empty Root domain containing minimal users.

Number of Users in Domain: Domains with the least amount of users are generally the best domains to go first since the number of users affected is less.

Use the following procedure to install the first Windows 2008 R2 DC to an existing Domain.



On an existing Windows 2003 DC



Review the following settings in the Default Domain Controllers policy



Microsoft network server: Digitally sign communications (always)

ii. Domain member: Digitally encrypt or sign secure channel data



iii. Record their current settings for future reference.



We may want to export the Default Domain Controllers policy for future reference as well.


Install Windows 2008 R2



Configure Static IP and appropriate DNS and WINS settings.



Optional: Add the server to the domain it will be a DC for.






Run DCPromo



AD Domain Services binaries will be installed.



OS Compatibility

  • i. A warning about a new more secure setting implemented called

Allow cryptography algorithms compatible with Windows NT 4.0, which by default disables NT4 SP3 and earlier versions of cryptology. This is

only of concern if we have NT4, non-Microsoft SMB, or NAS devices joined to the domain. If that is the case we may need to change this setting after the DCPromo is complete. ii.


Click Next

  • e. Deployment Configuration



Select Existing forest


Select Add a domain controller to an existing domain


Click Next

  • f. Network Credentials



Type the name of a domain in the forest.



This does not need to be the name of the domain we are joining.


Enter the credentials of an Enterprise Admin or Domain Admin.



Click the Set button


Click OK


Click Next

  • g. Select Domain



Select the domain to join


Click Next

  • h. Select a Site



Select which site to place the DC in.


Click Next

  • i. DC Options



Deselect DNS server



We will be using the existing DNS server.



Select Global Catalog Server


Click Next

  • j. Database, Log, and SYSVOL Locations



Change the drive letter for these locations as needed.


Click Next

  • k. Restore Password



Type the DS Restore password



Document and save



Click Next

  • l. Summary



Review the summary


Optional: Click Export Settings to save an unattended install file for

future use.



Click Next


Wait as the DC is installed.


Completing the Install

  • a. Click Finish

  • b. Click Restart Now


When the server reboots review the Default Domain Controllers policy settings

  • a. Microsoft network server: Digitally sign communications (always)

  • b. Domain member: Digitally encrypt or sign secure channel data (always)

  • c. If these values changed (to enabled) then we may need to verify that all clients and servers can still communicate to the domain, or we can revert the

settings back to their previous value.


Review the Allow cryptography algorithms compatible with Windows NT 4.0 setting.

  • a. This setting only applies to Windows 2008 DC’s, thus clients authenticating to Windows 2003 DC’s are not affected by this new setting.

  • b. Change this setting as needed to support NT 4.0 or non-Microsoft SMB clients.

  • c. The default setting is Not Configured, which means the policy is Disabled. We must configure the option as Enabled to actually change the setting.


Repeat this procedure once for every Domain in the Forest.

Transferring and Placing Operation Master Roles

In previous versions of Windows Server the Operations Master Roles were known as Flexible Single Master Operations (FSMO). In Windows 2008 these are now known as the Operation Master Roles.

Transferring these roles to a Windows 2008 R2 Domain Controller is not a requirement, but it may provide we additional benefits or functionality.

Schema Master and Domain Naming Master No added features or functionality are introduced with Window 2008. We can transfer these roles to a Windows 2008 DC or keep them on Windows 2003.

PDC Emulator If we transfer the PDC emulator operations master role to a Windows Server 2008 R2 domain controller, or we add a read-only domain controller (RODC) to domain, all the following will occur when the role is transferred.

Note: The role is automatically transferred to a Windows 2008 DC if we add a read-only DC.


The following new well-known and built-in groups are created:

  • a. Builtin\IIS_IUSRS

  • b. Builtin\Cryptographic Operators

  • c. Allowed RODC Password Replication Group

  • d. Denied RODC Password Replication Group

  • e. Read-only Domain Controllers

  • f. Builtin\Event Log Readers

  • g. Enterprise Read-only Domain Controllers (created only on the forest root domain)

  • h. Builtin\Certificate Service DCOM Access


The following group memberships are established:

  • a. IUSR security principal added to the Builtin\IIS_IUSRS group


The following groups are added to the Denied RODC Password Replication Group:

  • a. Group Policy Creator Owners

  • b. Domain Admins

  • c. Cert Publishers

  • d. Domain Controllers

  • e. Krbtgt

  • f. Enterprise Admins

  • g. Schema Admins

  • h. Read-only Domain Controllers


The following new, additional security principals are created in the forest root


  • a. IUSR

  • b. Owner Rights


The Network Service security principal added to Builtin\Performance Log Users


The Well-Known-Security-Id-System security principal is renamed to System

Remember the PDC Emulator of the forest root domain should be configured as the authoritative time server for the forest. When transferring this role, but sure to transfer the SNTP configuration of the server as well.

To retrieve the SNTP settings

Net time /querysntp

To set the SNTP settings

Net time /

RID Master and Infrastructure Master No added features or functionality are introduced with Window 2008. We can transfer these roles to a Windows 2008 DC or keep them on Windows 2003.

Review best practices for Operation Master role placement and transfer the role to an appropriate Windows 2008 R2 servers at convenience. All we need to do is build the new Windows 2008 R2 domain controller and transfer the Operations Master Role to the new DC.

Replacing Existing Windows 2003 DC / DNS Servers with Windows 2008 R2

There are several new record types available in Windows 2008 DNS that are not supported in Windows 2003. If we plan on using these record types we should upgrade all DNS server as soon as possible. If these new record types are not currently needed in environment we can safely mix Windows 2003 and 2008 DNS servers.

This process is just a guideline. There are many ways to replace existing DNS servers. However, this approach is the most efficient, and it assumes the following

A fault tolerant DNS infrastructure

DC’s are not being used as application servers as well.

All DNS servers are also DC’s and all or DNS zones are Active Directory Integrated.


Demote the existing Windows 2003 DC/DNS Server

  • a. Record current IP Address settings for future reference.

  • b. Remove from the Domain

  • c. Power Off


From the DNS Console on another Server

  • a. Remove any Name Server (NS) records that point to the server just removed.


Build a new Windows 2008 R2 Server

  • a. Configure Static IP (same as previous server) and appropriate DNS and WINS settings.

  • b. Optional: Add the server to the domain it will be a DC for.

  • i. Reboot

  • c. Run DCPromo

  • i. Follow the same installation procedure as specified above with the following changes



DC Options

  • 1. Select DNS server

  • 2. Select Global Catalog Server

  • d. Unable to create Name Server record in DNS error message

  • i. Click Yes to continue. This is caused when not joining the domain prior



to running DCPromo, and will be fixed once the server is rebooted.

  • e. Complete the installation per the previous instructions.


Verify DNS zones have replicated to the new server.


Repeat for each DNS/DC server.


It’s typical for WINS to be installed on Domain Controllers. Use the same basic replacement approach for WINS as we did for DNS. Make sure we record the configuration settings so we can reconfigure the new server the same way.

Raise Domain Functional Level


For each domain where all DCs are now Windows 2008 R2

  • a. Login to a Windows 2008 R2 DC

  • b. Run Active Directory Users and Computers

i. ii. Right Click the domain name Select Raise domain functional level iii. iv. Select Windows
Right Click the domain name
Select Raise domain functional level
Select Windows 2008 R2
Click Raise
Click OK, OK

Raise Forest Functional Level


Login to the Forest Root domain as an Enterprise Admin


Launch Active Directory Domains and Trusts

  • a. Right Click the Active Directory Domain and Trusts

  • b. Select Raise Forest Functional Level

Raise Domain Functional Level 1) For each domain where all DCs are now Windows 2008 R2
  • c. Select Windows 2008 R2

  • d. Click Raise

  • e. Click OK, OK

Enable AD Recycle Bin

By default, Active Directory Recycle Bin in Windows Server 2008 R2 is disabled. To enable the AD Recycle Bin the following requirements must be met.


Completed ALL Schema updates listed in the Preparing the Forest and Domains


section above All domain controllers in Active Directory forest must be running Windows Server


2008 R2. Raise the functional level of Active Directory forest to Windows Server 2008 R2.

To enable Active Directory Recycle Bin use the following procedure.


Login to the Windows 2008 R2 Domain controller that holds the Schema Master

  • a. We must login as the built-in Administrator with the Enterprise Admin and Schema Admin permissions.


Launch Windows PowerShell


Type the following command, then press enter

import-module activedirectory


Type the following command, then press enter (this command is all one line)

  • a. Change the items in bold as required for the environment


Enable-ADOptionalFeature -Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=domain,DC=com’ -Scope ForestOrConfigurationSet -Target ‘domain.comA warning will appear WARNING: Enabling 'Recycle Bin Feature' on 'CN=Partitions,CN=Configuration,DC=domain,DC=com' is an irreversible action!

We will not be able to disable 'Recycle Bin Feature' on 'CN=Partitions,CN=Configuration,DC=domain,DC=com ' if we proceed.

  • a. Press Y, then Enter to continue



  • a. If we receive an insufficient access rights error

  • i. We did not login as the built-in Administrator,

or that account is not a member of the Enterprise Admins, Domain Admins, or Schema Admins groups.

  • b. If we receive an referral error

  • i. We are not logged into the DC containing the


Schema Master role. To verify that Active Directory Recycle Bin is enabled

  • a. Launch ADSIEdit.msc

  • b. Connect to the Configuration partition of the forest root domain.

  • c. Right click the CN=Partitions container.

    • i. Select Properties In the details pane, locate the msDS-


EnabledFeature attribute

  • d. Confirm that its value is set to the configured value.

Configuring Tombstone Lifetime The tombstone lifetime in an Active Directory forest determines how long a deleted

Configuring Tombstone Lifetime

The tombstone lifetime in an Active Directory forest determines how long a deleted object (called a “tombstone”) is retained in the Active Directory database. The tombstone lifetime is determined by the value of the tombstoneLifetime attribute on the Directory Service object in the configuration directory partition.

In Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service Pack 2 (SP2), Windows Server 2008, or Windows Server 2008 R2 operating systems, when the tombstoneLifetime attribute is set to null its default value is considered to be 180 days.

In Windows 2000 Server, Windows Server 2003, or Windows Server 2003 R2 operating systems, when the tombstoneLifetime attribute is set to null its default value is considered to be 60 days.

If we upgrade domain controller to Windows Server 2008 or Windows Server 2008 R2 from Windows 2000 Server, Windows Server 2003, or Windows Server 2003 R2 operating, as opposed to performing a clean installation of Windows Server 2008 or Windows Server 2008 R2 operating systems, it is recommended that we manually set the value of tombstoneLifetime to 180 days.

Run the following PowerShell (PS) commands to determine the current tombstoneLifetime setting and configure this value if needed.

Load the PS AD module

import-module activedirectory

Find the current value of tombstoneLifetime (all one line)

Get-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=domain,DC=com” -properties tombstonelifetime

Configure the value of tombstoneLifetime (all one line)

Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=domain,DC=com” -Partition “CN=Configuration,DC=domain,DC=com” -Replace:@{“tombstoneLifetime” = 180}

Redirect Users and Computers

By default all new users are created in CN=Users and all new Computer object are created in CN=Computers. However, neither of these locations allow Group Policies to be applied. We can choose to change these default locations to an OU where group policy could be applied.

This not new to Windows 2008 (it was available in Windows 2003), but it does require that the domain functional level be at Windows 2003 or higher. To change these locations use the following commands.

Redirusr ou=userou,dc=domain,dc=com

Redircmp ou=computerou,dc=domain,dc=com