The things that are better left unspoken : Microsoft Windows Server 2008, Active Directory

Active Directory Services and their System Center Management Packs

Sander Berkouwer — Mon, 13 May 2013 06:06:32 GMT

As you might be aware, every Microsoft technology has the requirement to be manageable through PowerShell and System Center. Manageability through System Center is done through Management Packs. (MPs).

While I discussed the PowerShell manageability stories for the five Active Directory services last Saturday, below is the overview of the availability and functionality of the Management Packs (MPs) for the five Active Directory services:

Active Directory Domain Services

For Windows Servers running the Active Directory Domain Services as Domain Controllers, a System Center Management Pack has been available for ages, even before the products responsible for management were labeled ‘System Center’ (System Center Operations Manager was called MOM Server and System Center Configuration Manager was called SMS Server).

The Active Directory Domain Services Management Pack for System Center provides both proactive and reactive monitoring of your Active Directory deployment. It monitors events that various Active Directory components and subsystems place in the Application, System, and Service event logs. It also monitors the overall health of the Active Directory system and provides alerts for critical performance issues.

When used with the Management Pack for the Windows Server Operating System, the DNS Server Role, File Services, Group Policy and DFS Replication, a complete management view starts to emerge, where you can monitor the health of your Domain Controllers.

The latest version (v6.0.8070.0) adds support for Windows Server 2012.

Download MP for AD Domain Services v6.0.8070.0

Also available is a System Center Integration Pack, that allows System Center 2012 - Orchestrator to connect to your Active Directory Server to automate Identity and Access management tasks.

Download System Center Integration Pack for Active Directory v7.0

Active Directory Lightweight Directory Services

The Active Directory Lightweight Directory Services (AD LDS) Management Pack provides both proactive and reactive monitoring of your AD LDS deployment running on Windows Server 2008 and Windows Server 2008 R2. It monitors events that are placed in the Application, System, and Service event logs by various Active Directory Lightweight Directory Services components and subsystems. It also monitors the overall health of the Active Directory Lightweight Directory Services system and alerts you to critical performance issues.

Download MP for AD Lightweight Directory Services v6.0.7220.0

Active Directory Certificate Services

The System Center Management Pack for Active Directory Certificate Services provides an early warning to administrators on issues that could affect services so they can investigate and take action, if necessary.

Two Management Packs for Active Directory Certificate Services are currently available. An ‘old’ Management Pack exists to manage Certification Authorities running on Windows Server 2008 and Windows Server 2008 R2. This Management Pack follows the 6.x version numbering. A completely new 7.x Management Pack is available alongside the 6.x version and enables management of Certification Authorities on Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012.

Note:
The Management Packs for Active Directory Certificate Services monitors the core Certification Authority, but does not monitor Certificate Services role services (such as the Online (OCSP) responder, Network Device Enrollment Services (NDES), Certificate enrollment web services, NDES, or CA web enrollment).

Download MP for AD Certificate Services v6.0.7231.0
Download MP for Windows Server 2012 AD Certificate Services v7.0.8560.0

Active Directory Federation Services

The System Center Management Pack for Active Directory Federation Services 1.x has been available since September 2007 and for Active Directory Federation Services 2.x since June 2010.

The Management Pack for Active Directory Federation Services offers the ability to detect service outages, operational errors and operational warnings. It also alerts on configuration issues and background tasks failures. Auditing can also be monitored, as well as the communication between the federation server and the federation server proxy. With the Management Pack you can be notified of malformed access requests and the health of the Secure Sockets Layer (SSL) certificate of the federation passive website in Internet Information Services (IIS).

Depending on the version of Active Directory Federation Services, you can choose between the 6.x version and the 7.x version of the Management Pack, where version 6.x can be used to monitor Active Directory Federation Services 1.0 and version 7.x can be used to monitor Active Directory Federation Services 2.0 (available as a separate download for Windows Server 2008 R2) and 2.1 (bundled with Windows Server 2012).

Download MP for Windows Server 2003 R2 AD Federation Services v6.0.5000.0
Download MP for AD Federation Services 2.0 and 2.1 v7.0.8560.0

Active Directory Rights Management Services

The System Center Management Pack for Active Directory Rights Management Services (AD RMS) has been available since July 2011 and monitors the performance and availability of the Windows Server 2008 SP2 or Windows Server 2008 R2 versions of AD RMS. By detecting, alerting on, and automatically responding to critical events and performance indicators, this Management Pack helps indicate, correct, and prevent possible AD RMS related service outages. The System Center Monitoring Pack for Active Directory Rights Management Services for Windows Server 2008 SP2 or Windows Server 2008 R2 helps ensure that your AD RMS components are available and working correctly.

In September 2012, Microsoft released a version 7.x of the Management Pack for Active Directory Rights Management Services. This Management Pack can be used to manage Rights Management Services, running on Windows Server 2012. For Rights Management Services running on Windows Server 2008 and Windows Server 2008 R2, the 6.0.7xxx.x version of the Management Pack is the one to use. For sturdy Rights Management Servers on Windows Server 2003, the 6.0.5000.0 version of the Management Pack offers the desired monitoring capabilities.

Download MP for Windows Server 2003 Rights Management Services v6.0.5000.0
Download MP for AD Rights Management Services v6.0.7597.0
Download MP for Windows Server 2012 AD Rights Management Services v7.0.8560.0

Related blogposts

Active Directory Domain Services Management Pack for System Center updated last week
System Center Monitoring Pack for Active Directory was updated today

Related downloads

System Center Management Pack for Windows Server Operating System
System Center Management Pack for Windows 8 Client Operating System

Active Directory Services on Server Core installations

Sander Berkouwer — Thu, 09 May 2013 18:58:18 GMT

Windows Server 2012 is a major leap forward for Server Core installations of Windows Server. Not only are Full installations of Windows Server convertible back and forth to Server Core installations without reinstallation, a whole slew of new Server Roles have become available for installation on the mean, clean Server Core installations.

Active Directory Domain Services have been available since day 1 on Server Core installations, but what about the other four services? Can you install these on Server Core?

The table below shows the Active Directory services, available for installation on Server Core installation of Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012:

You can install the Active Directory Services on Server Core installations in four ways:

From the command-line of the Server Core installation using:
1. dism.exe, pkgmgr.exe or the Install-WindowsFeature / Add-WindowsFeature PowerShell Cmdlet on Windows Server 2012
2. dism.exe or pkgmgr.exe or the Add-WindowsFeature PowerShell Cmdlet (after you’ve manually installed PowerShell and have imported the ServerManager PowerShell module) on Windows Server 2008 R2
3. ocsetup.exe or pkgmgr.exe on Windows Server 2008
From the command-line of the Server Core installation over a Remote Desktop Connection.
From a remote command-line of a Full installation of Windows, a full installation of Windows Server or another Server Core installation of Windows Server through remote PowerShell or Windows Remote Management (winrs.exe).
From Server Manager in Windows Server 2012, targeted at a Server Core installation of Windows Server 2012. This method does not work with Windows Server 2008 or Windows Server 2008 R2.

Related blogposts

Installing Server Core Domain Controllers
How to install a Server Core R2 Domain Controller
The importance of Server Core
Server Core Roles and Features in 2008 R2
Some Server Core Domain Controllers heading for a dead end street
How to get going with PowerShell in Server Core R2

KnowledgeBase: You cannot use redirusr.exe and redircmp.exe in the Windows Server 2008 DFL on Windows Server 2008

Sander Berkouwer — Mon, 15 Apr 2013 15:29:53 GMT

In the past years, I’ve found many systems and many errors. Today, I’m sharing behavior in Microsoft Windows Server that had me frown and chuckle. A bug in Active Directory code I’ve been grateful for, since it illustrates the nature of software.

Note:
This behavior has not been publicized in the Microsoft KnowledgeBase (yet).

In the past two versions of Windows Server, the Active Directory team has made an effort to migrate all of the command-line stuff to PowerShell. Two of the command-line tools I still use frequently, however, have not been converted to PowerShell: redirusr.exe and redircmp.exe.

redirusr.exe and redircmp.exe were my partners in crime for the last couple of years, in which I setup loads of Active Directory structures for small sized organizations, following the Best Practice Active Directory Design for Managing Windows Networks. I used them in newly setup environments to automatically place newly created computer and user accounts in specific Organizational Units (OUs) in Active Directory.

A short history on redirusr.exe and redircmp.exe

Microsoft introduced the ability to change the default container (or Organizational Unit) where new users and computers are stored in the Windows Server 2003 Domain Functional Level (DFL). Both tools won’t work in Windows 2000 Domain Functional Level. When using the commands on a Windows Server 2008-based Domain Controller for a domain with the Windows 2000 Domain Functional Level both tools error out with the following message:

Error, unable to modify the wellKnownObjects attribute. Verify that
the domain functional level of the domain is at least Windows Server 2003:
Unwilling To Perform
Redirection was NOT successful.

This is by design. As the error indicates you need to raise the Domain Functional Level (DFL) to Windows Server 2003. It is not the subject of this blogpost.

Using redirusr.exe and redircmp.exe

On a Windows Server 2003-based Domain Controller and Windows Server 2008-based Domain Controller in an Active Directory domain with the Windows Server 2003 Domain Functional Level (DFL) you can use the following commands:

dsadd ou "OU=Redirected Users OU,DC=DomainName,DC=Tld"
dsadd ou "OU=Redirected Computers OU,DC=DomainName,DC=Tld"
redirusr "OU=Redirected Users OU,DC=DomainName,DC=Tld"
redircmp "OU=Redirected Computers OU,DC=DomainName,DC=Tld"

These commands will add two Organizational Units with names Redirected Users OU and Redirected Computers OU. After creation it will run the two commands to automagically place new useraccounts and computeraccounts in the new OUs.

The below two commands will output the following message, when successful:

Redirection was successful.

Now for the bug…

I expected the above commands to work on a Windows Server 2008-based Domain Controller for an Active Directory domain with the Windows Server 2008 Domain Functional Level (DFL)…

Unfortunately this is not the case. The error message is:

Error, unable to modify the wellKnownObjects attribute. Verify that
the domain functional level of the domain is at least Windows Server 2003:
Referral
Redirection was NOT successful.

Obviously the Verify that the domain functional level of the domain is at least Windows Server 2003 part of the message is a standard message, but the part behind it is different, compared to the Windows 2000 Domain Functional Level output. It is apparently willing to perform, but was referred.

This is actual behavior on a Domain Controller running Windows Server 2008 RTM. (or Windows Server 2008 with Service Pack 1, if you want to be 100% correct)

Unfortunately there is no way to redirect users and computers using the redirusr.exe and redircmp.exe commands on a Windows Server 2008 RTM-based Domain Controller in an Active Directory domain with the Windows Server 2008 Domain Functional Level (DFL).

The workaround

To use the redirusr.exe and redircmp.exe commands in an Active Directory domain with the Windows Server 2008 Domain Functional Level (DFL), either:

Install Service Pack 2 on a Windows Server 2008-based Domain Controller and run the commands on this Domain Controller, or
Upgrade a Domain Controller to Windows Server 2008 R2 or Windows Server 2012 and run the commands on this Domain Controller.

MS013-032 Vulnerability in Active Directory Could Allow Remote Code Execution (Important)

Sander Berkouwer — Wed, 10 Apr 2013 08:25:59 GMT

It’s not often, that Active Directory Domain Controllers get security updates. The Active Directory Domain Services Server Role is one of the most robustly written code, as I pointed out in an earlier blogpost on Statistics on Active Directory-related Security Bulletins. Since 2001, Microsoft has issued 18 Security Bulletins with patches to address issues in Active Directory Directory Services, Active Directory Lightweight Directory Services and ADAM.

Yesterday, during the April 2013 Patch Tuesday, Microsoft has released a new Active Directory-related security bulletin: MS013-032.

This security update resolves a privately reported vulnerability in Active Directory. The vulnerability could allow denial of service if an attacker sends a specially crafted query to the Lightweight Directory Access Protocol (LDAP) service, that leads to excessive memory consumption and could cause the LDAP service to become non-responsive. This issue was privately reported to Microsoft and documented as CVE-2013-1282

This Security update is not classified as Critical, since an attacker must have valid logon credentials to exploit this vulnerability. The vulnerability could not be exploited remotely by anonymous users. However, the affected component is available remotely to users who have standard user accounts. In certain configurations, anonymous users could authenticate as the Guest account.

Affected Operating Systems

This security update is rated Important for Active Directory, Active Directory Application Mode (ADAM), Active Directory Lightweight Directory Service (AD LDS), and Active Directory Services on the following, currently supported, Windows Server Operating Systems:

Active Directory on Windows Server 2003 SP2 x86
Active Directory on Windows Server 2003 SP2 x64
Active Directory Application Mode (ADAM) on Windows Server 2003 SP2 x86
Active Directory Application Mode (ADAM) on Windows Server 2003 SP2 x64
Active Directory Services on Windows Server 2008 SP2 x86
Active Directory Services on Windows Server 2008 SP2 x64
Active Directory Application Mode (ADAM) on Windows Server 2008 SP2 x86
Active Directory Application Mode (ADAM) on Windows Server 2008 SP2 x64
Active Directory Services on Windows Server 2008 R2
Active Directory Application Mode (ADAM) on Windows Server 2008 R2
Active Directory Services on Windows Server 2008 R2 SP1
Active Directory Application Mode (ADAM) on Windows Server 2008 R2 SP1
Active Directory Services on Windows Server 2012

This security update is rated Low for Active Directory Application Mode (ADAM) and Active Directory Lightweight Directory Services (AD LDS) on the following, currently supported, Windows client Operating Systems:

Active Directory Application Mode (ADAM) on Windows XP SP3
Active Directory Application Mode (ADAM) on Windows XP Professional x64 SP2
Active Directory Lightweight Directory Service (AD LDS) on Windows Vista SP2 x86
Active Directory Lightweight Directory Service (AD LDS) on Windows Vista SP2 x64
Active Directory Lightweight Directory Service (AD LDS) on Windows 7 x86
Active Directory Lightweight Directory Service (AD LDS) on Windows 7 x64
Active Directory Lightweight Directory Service (AD LDS) on Windows 7 SP1 x86
Active Directory Lightweight Directory Service (AD LDS) on Windows 7 SP1 x64
Active Directory Lightweight Directory Service (AD LDS) on Windows 8 x86
Active Directory Lightweight Directory Service (AD LDS) on Windows 8 x64

The security update addresses the vulnerability by correcting how the LDAP service handles specially crafted LDAP queries.

On all affected Operating Systems, except for Windows 8 and Windows Server 2012, this security update replaces Security update MS011-095.

Guidance

You are urged to test and implement the update corresponding to the Security Bulletin on the affected Operating Systems running the aforementioned Active Directory services.

MS08-003 Security Update for Active Directory
A New Vulnerability in Active Directory (MS09-018)
MS11-095 Vulnerability in Active Directory could allow Remote Code Execution (Important)
Statistics on Active Directory-related Security Bulletins

PowerShell, LDIFDE, CSVDE and Protection from Accidental Deletion

Sander Berkouwer — Fri, 28 Dec 2012 06:48:54 GMT

When you build test environments regularly, at some point you’ll want to fill your Active Directory quickly. If, for instance, you have a data set with Organizational Units (OUs), user accounts and groups, you’ll want to quickly import this data. If, on the other hand, in your business you’re allowed to use the user information from a production Active Directory environment in your test environment, you might even opt to export and import this information.

Besides restoring backups from Domain Controllers to the test environment, Microsoft offers three tools to import exported data:

Import-CSV & New-ADOrganizationalUnit
Csvde.exe
Ldifde.exe

From the surface, these three tools seem to enable you to achieve the same goal, but they don’t. The end result after importing and exporting data is not the same between these three tools.

When you use the New-ADOrganizationalUnit PowerShell Cmdlet (together with the Import-CSV Cmdlet in this case) in a script, unless you specify otherwise, the created Organizational Units will be protected from accidental deletion.

When you use ldifde.exe or csvde.exe tool to (export and) import Organizational Units (OUs), these OUs will be created without protection from accidental deletion.

Note:
The Active Directory Best Practices Analyzer will display a warning when not all Organizational Units (OUs) are protected from accidental deletion.
More info

Protection from accidental deletion looks like a simple checkmark in the properties of an Active Directory object, but it’s not. Underlying is a set of ACLs that prevent anyone from deleting the object. But since PowerShell has the logic inside for Protection from accidental deletion, to fix the newly created Organizational Units, use the following PowerShell one-liner:

Get-ADOrganizationalUnit -filter {name -like "*"} -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

Concluding

With new functionality in new Operating Systems and Active Directory levels, don’t expect the old tooling you’ve learned to trust and love, to be updated.

Preventing OUs and Containers from Accidental Deletion

Active Directory in Hyper-V environments, Part 7

Sander Berkouwer — Fri, 16 Nov 2012 06:51:49 GMT

For a while, Microsoft’s KnowledgeBase article 976424, titled Error code when the kpasswd protocol fails after you perform an authoritative restore: "KDC_ERROR_S_PRINCIPAL_UNKNOWN", has been available to solve issues with unexpected behavior after authoritatively restoring the krbtg account on Windows Server 2008 and Windows Server 2008 R2-based Domain Controllers.

Now, in KnowledgeBase article 2784261, titled Recommended hotfixes and updates for Windows Server 2012-based Failover Clusters, Microsoft recommends the hotfix for Windows Server 2012-based Failover Clusters, quoting:

Install on every domain controller running Windows Server 2008 Service Pack 2 or Windows Server 2008 R2 in order to add a Windows Server 2012 failover cluster. Otherwise Create Cluster may fail when attempting to set the password for the cluster computer object with error message: CreateClusterNameCOIfNotExists (6783): Unable to set password on <ClusterName$>

These days, most fail-over clusters are deployed to provide a robust, scalable and highly-available virtualization platform using Hyper-V. If you plan a Windows Server 2012-based Fail-over Cluster in your environment running Windows Server 2008 or Windows Server 2008 R2-based Domain Controllers, apply this hotfix during the next service window.

Note:
Domain Controllers need to restart to apply this hotfix.

In this series

Active Directory in Hyper-V environments, Part 1
Active Directory in Hyper-V environments, Part 2
Active Directory in Hyper-V environments, Part 3
Active Directory in Hyper-V environments, Part 4
Active Directory in Hyper-V environments, Part 5
Active Directory in Hyper-V environments, Part 6

Tipjar

Robert Smit, a Dutch Microsoft MVP on Fail-over Clustering and my friend, pointed this out to me on twitter this morning.

DCPROMO Advanced Mode, what does it do?

Sander Berkouwer — Fri, 14 Oct 2011 12:10:33 GMT

In the past 11 years, Microsoft has released four versions of Windows Server on which you could install Active Directory. On all these platforms, Microsoft offered two ways to promote a server to a Domain Controller.

In this blogpost I’ll reveal the differences between the advanced mode and normal mode for dcpromo.exe for the Windows Server 2003 family and the Windows Server 2008 family. I’ll also cover the differences between using the Configure your Server wizard and dcpromo.exe on Windows 2000 Server.

Windows 2000 Server

Active Directory was introduced in Windows 2000 Server. Overshadowing User and Computer management from the Windows NT era, Active Directory introduced totally new concepts. To make the promotion of a Domain Controller not too daunting, Microsoft shipped two ways to accomplish this:

Configure your Server wizard

The Configure Your Server wizard is a special wizard, that you can use to transform a vanilla Windows 2000 Server into a Domain Controller. Since, at installation you already need to provide a keyboard lay-out, computer name and time zone, you can use the wizard to assign a static IPv4 address and install Active Directory Domain Services on it.

One important thing to note is that the Configure Your Server wizard can only be used to create a new Domain Controller for a new domain in a new forest, and many options have gone missing. You will need to provide a DNS domain name and NetBIOS domain name, but you cannot specify the location of Active Directory logs, the Active Directory database or the System Volume (SYSVOL). Also, the wizard assumes you’re OK with a blank Directory Services Restore Mode password.

A blank Directory Services Restore Mode password is a serious security issue, since anyone with physical access to the Domain Controller can boot it into Directory Services Restore Mode and press Enter as the password. It’s better to use dcpromo.exe to promote a server to a Domain Controller.

Dcpromo.exe

Of course, Windows 2000 Server came with dcpromo.exe. An admin could use it to promote a server to a Domain Controller. In Windows 2000 Server, dcpromo.exe is only available in one mode.

Windows Server 2003 & 2003 R2

In Windows Server 2003, both normal mode and advanced mode for dcpromo.exe are available, but if you want to access the advanced mode you will need to resort to the commandline. Where firing up dcpromo.exe will present you with the normal mode, you will have to run dcpromo.exe /adv to enter advanced mode.

New Domain Controller for a new forest

Why any Active Directory admin would choose the advanced mode to promote a server to a Domain Controller for a new domain in a new forest is beyond me. There is no difference between these two modes in this scenario.

Also, in both modes you can choose to implement a Domain Controller for a new domain, a new child domain in an existing domain tree or a new domain tree in an existing forest.

New Domain Controller for an existing domain/forest

One difference between advanced mode and normal mode can be found when you add a server as a Domain Controller for an existing domain or as a Domain Controller for a new domain in an existing forest. In this case you’ll be presented with the following screen:

In advanced mode you can use the Install from Media (IfM) option. You can create media by making System State Backups for an existing Domain Controller in the same domain as where you want to deploy the additional Domain Controller.

Windows Server 2008 & 2008 R2

In Windows Server 2008 R2, after installing the Active Directory Domain Services role, you can run dcpromo.exe. On the Welcome screen you are immediately presented with the option to Use advanced mode installation.

New Domain Controller for a new forest

When you promote the server to a new Domain Controller for a new forest, using Advanced mode, only offers you one additional screen, compared to the standard mode. This screen (as depicted below) offers to enter the NetBIOS Name for the domain.

By default, the value depicted in the field Domain NetBIOS name would be the part of the DNS domain name that distinguishes the domain from the domain structure. In the screen you have the option to change the NetBIOS name for the domain. One of the reasons why you would want to do that, would be to change the name depicted in the logon screen of Windows clients like Windows 2000 Professional and Windows XP Professional.

New Domain Controller for an existing domain/forest

When you look at the advanced mode options when you add the server as a Domain Controller for an existing forest, a lot more options emerge.

First, in the Choose a Deployment Configuration screen, an extra option emerges, that allows for deployment of a Domain Controller for a new domain tree root instead of a new child domain. This allows you to create a pokkiewokkie.local domain in the same forest as the hakkietakkie.local domain and its child domains, like korea.hakkietakkie.local and china.hakkietakkie.local. (these domain names are purely fictional)

The next difference between normal and advanced mode dcpromo is the ability to Install from Media (IfM) in the advanced mode. When you create an IfM-package on a Domain Controller (of the same type as you’re installing), you can use that package to limit replication of Active Directory data. You can create IfM packages, including the information in the System Volume using ntdsutil.exe, as described here. Using IfM is useful when you want to deploy a Domain Controller in a remote site with limited (available) bandwidth.

Last, but certainly not least is the ability to specify a Source Domain Controller to use for replication during the promotion of the Domain Controller. While by default dcpromo.exe would find a suitable replication partner using the Active Directory topology, you could use this option if you want to avoid additional load on critical Domain Controllers or to specify a Domain Controller in times when replication is not working adequately.

Concluding

This post clearly shows the evolution of the Domain Controller promotion process since Windows 2000 Server. Through the years, Microsoft has laid down the groundwork in terms of knowledge and readiness among admins, and has hidden a lot of new features in a more advanced but more daunting ‘advanced mode’ for Active Directory professionals..

After reading this blogpost, you’ll know whether to use advanced mode to accomplish your goals or just to make yourself feel like a big shot Active Directory administrator.

How to effectively defend against Morto.A in the enterprise

Sander Berkouwer — Fri, 02 Sep 2011 19:59:00 GMT

Whenever a worm utilizes the normal access and daily tools systems admins use, there is a significant problem. After all, shutting down the attack vector suddenly isn’t that easy. So, without making dramatic changes to your environment, how can you rest assured?

About Win32/Morto.A

One of the latest threats to use administrative access is Win32/Morto. This worm scans entire IP address ranges for port 3389 and uses the Remote Desktop Protocol (RDP) to log on to the Remote Desktops of Windows machines through guessing usernames and passwords. When it succeeds it uses an exploit to gain administrative access to try and infect other machines.

We’re now seeing the first version of this worm, but since the modest success of it, we might see other incarnations sporting longer username and password lists alongside other exploits. In a worst case scenario, Morto might evolve to include brute forcing techniques to gain access to machines.

The problem

Remote Desktop Protocol (RDP) is used heavily by admins to log on to workstations and servers. Although manageability features in newer versions of Windows allow admins to remotely perform (routine) actions through PowerShell, Group Policy Preferences and Server Manager, many admins still rely on Remote Desktop. Especially when they need to change settings in non-Microsoft products running on top of their machines. Switching off Remote Desktop is not seen as a solution to defend against this threat.

Many Internet-facing Windows webservers have Remote Desktop enabled to allow the admin to manage the server remotely. Either from the office or home, since flexibility is key when the box gets compromised.

Many organizations work with passwords to allow their employees to authenticate. In recent versions of Windows, password complexity is enforced by default, but in many organizations people are allowed to use weak passwords, either for (reduced) single sign-on or other reasons. Two factor authentication is not widely used, especially not for service accounts.

Shutting off Remote Desktop is not an option in these situations, so how does one effectively defend against Morto?

Defending against Morto.A

You can effectively battle Morto.A in many ways. I’ll describe the countermeasures below. Combining multiple of these countermeasures increases your success:

Apply a stringent and complete authentication policy

A good defense is to use strong passwords throughout the networking infrastructure. Since tokens or smartcards can not be implemented overnight and are not suitable for all authentication purposes (for instance service accounts), this is probably the best short term defense.

Windows and Active Directory both include password policies. Since Windows Server 2008, the option ‘Password must meet complexity requirements’ is default enabled, requiring newly set passwords to adhere to complexity rules. These rules include the use of at least 7 uppercase and lowercase characters, numbers and non-alphanumeric characters (3 out of 4) and prevent the use of a significant portion of the logon name. Other tidbits of the default password policies include a minimum length of six characters.

In many environments, these password policies were (temporarily) disabled. From an authentication security point of view this is horrendous, since it allows anyone to use weak passwords. Even admins can use weak passwords to secure the service accounts, most of which are able to log on anywhere.

You have a couple of options on getting your users to use stronger passwords:

Re-enable password policies
For a stand-alone server, this is accomplished through the Local Security Policy (secpol.msc) under Account Policies in the Password Policy.
To change the password policies for an entire Active Directory domain, open the Group Policy editor (gpedit.msc) and browse for the default domain policy. Here under Computer Configuration, then Windows Settings, Security Settings, Account Policies and finally under Password Policy change the settings for minimum password length and password complexity. Changing these setting in another group policy on the domain level, will lead to the above change in the default domain policy. Changing these settings on another level in Active Directory (for instance on a Site or Organization Unit will not have an effect on user accounts in the domain).
Off course, for your entire network, you might need to change these settings on all your domains.

Note:
If you want to restrict password policies to users of your Terminal servers only, you’ve set up your environment according to best practices and you’re using at least Windows Server 2008 Domain Controllers, you can also create a Fine-grained Password Policy to the ‘Remote Desktop Users’ group.
Clearing the ‘password never expires’ settings on user accounts
Getting everyone a new password is not as easy as re-enabling the default password policy. Some users may not be compelled to change their passwords (since the option ‘Password never expires’ is checked in the account properties), while other users still have a lease on their current passwords, that only compel them to change it in a couple of weeks. The below one-liner script will clear the ‘Password never expires’ for all user accounts in a certain Organizational Unit:

dsquery user "ou=useraccounts,dc=domain,dc=tld" | dsmod user -pwdneverexpires no
Setting the ‘User must change password at next logon’ attribute
Again, enabling password policies for new passwords and clearing the ‘password never expires’ settings is not enough. Users will still have passwords that don’t need to be changed, simply because these passwords are not at the end of their lifetime (as defined in the password policy). To force all users in a certain Organizational Unit to change their password, use the following one-liner:

dsquery user "ou=useraccounts,dc=domain,dc=tld" | dsmod user -mustchpwd yes

Secure Service Accounts

Changing passwords on Service Accounts is not a small change. Breaking essential services like Exchange Server or the backup is not an appropriate risk to take in order to defend against Morto.

On of the new features of Active Directory in Windows Server 2008 R2 is Managed Service Accounts. Managed Service Accounts (MSAs) are virtual domain accounts that can be used on Windows 7 and Windows Server 2008 R2 in Active Directory environments running Windows Server 2003 and Windows Server 2008 Functional levels. Domains at the Windows Server 2008 R2 functional level provide native support for both automatic password management and SPN management. This means, that when you’re only running Windows Server 2008 R2-based Domain Controllers, you don’t need to worry about Service Account passwords no more; Active Directory will take care of that (with the restriction that you can only use an MSA on one domain member).

Another route to prevent the misuse of Service Accounts by Morto, is to deny them rights to log on through Remote Desktop Services. You can achieve this simply by creating a Group Policy and specifying a group containing all Service Accounts in the ‘Deny log on through Remote Desktop Services’ under User Rights Assignment, under Local Policies, under Security Settings in the Windows Settings of the Computer Configuration.

Change the usernames for well-known accounts

Guessing the password for a built-in Administrator account would be any attackers first attack vector. Changing the name of these accounts is an effective way for you to prevent these attacks through Remote Desktop Services.

An alternative route would be to disable local administrator accounts and securing the domain administrator with a password no-one knows. Then, you might consider using accounts with administrative privileges for each of your systems administrators. Admin_SBerkouwer or SBerkouwer9 would be good ways to denote an account with administrative privileges I can use besides my non-priviledged SBerkouwer account.

Renaming local administrative accounts can be done through Group Policy.

I would like to add, this is a security best practice, I would like to see in any network.

Apply an environment-wide Password Lockout policy

While eradicating weak passwords throughout your enterprise is a good step, this on its own results on a more or less unmanageable network. Remote Desktop Servers might be unresponsive due to logon attempts and security logs might fill so quickly, tracing back to where Morto entered the network becomes impossible due to overwritten logs.

This is where Password Lockout comes to the rescue. Although Password Lockout policies are not enabled by default in any version of Windows or Active Directory, it is a best practice to detect and defend against guessing and brute forcing passwords.

The reason why Account Lockout policies are not enabled by default, is because they might hinder your people to log on and burden servicedesk personnel. Good lockout policies, therefore, are key. Setting a permanent account lockout after three invalid attempts will prove to be career suicide. Locking out an account for two minutes after ten invalid attempts would be equally effective against Morto, but would not hinder any normal person much.

In every Active Directory domain in your network, define an account lockout policy in the default domain policy under Windows Settings, Security Settings, Account Policies and finally under Lockout Policy. Changing these setting in another group policy on the domain level, will lead to the above change in the default domain policy. Changing these settings on another level in Active Directory (for instance on a Site or Organization Unit will not have an effect on user accounts in the domain).

Note:
If you want to restrict account lockout policies to users of your Terminal servers only, you’ve set up your environment according to best practices and you’re using at least Windows Server 2008 Domain Controllers, you can also create a Fine-grained Password Policy to the ‘Remote Desktop Users’ group.

Report on invalid logon attempts through auditing

After you’ve created password and account lockout policies, you can easily detect invalid logon attempts throughout your enterprise, right from the security logs of your Domain Controllers for domain accounts. For local accounts (for instance the local administrator accounts on the Remote Desktop Servers themselves) the security logs of the servers provide valuable information.

For Domain accounts you can put the ‘Audit account logon’ policy to good use. After you enable the auditing of failures in the default domain policy under Computer Configuration, Windows Settings, Security Settings, Local Policies and finally in Audit Policy. For Audit Account Logon Events and Audit Logon Events, enable the auditing of both success and failure.

Now, the events to look for and where to look for them depends on the Operating System versions of your Domain Controllers:

Windows 2000 Server-based Domain Controllers
When you’re running Windows 2000 Server-based Domain Controllers, you need to check the Security logs of all your Domain Controllers. Microsoft KnowledgeBase article 824209 explains how to download and use EventCombMT to ease this pain. EventCombMT has predefined filters to scan for invalid logon attempts and account lockout policies, but if you want to go commando you’ll want to report on the following events:

EventID	Source
529	Security
539	Security
644	Security
672	Security
675	Security
676	Security
681	Security
12294	SAM

Windows Server 2003-based Domain Controllers
In a domain with Windows Server 2003-based Domain Controllers or newer Domain Controllers, you can check the event log of one of the Domain Controllers, since the security events surrounding invalid logon attempts and account lockouts get replicated between all Domain Controllers. You’ll want to report on the following events:

EventID	Source
529	Security
539	Security
644	Security
672	Security
675	Security
676	Security
681	Security
12294	SAM

Windows Server 2008 and Windows Server 2008 R2-based Domain Controllers
In Windows Server 2008, new events were created with the new auditing policies. You’ll want to report on the following events:

EventID	Source
4625	Microsoft-Windows-Security-Auditing
4776	Microsoft-Windows-Security-Auditing
4777	Microsoft-Windows-Security-Auditing
12294	Directory-Services-SAM

For your Remote Desktop Hosts, it’s also important to scavenge the security logs. Using Group Policy from within Active Directory, make sure to audit for logon events and also start looking for events 529, 539 and 12294. These would indicate username and/or password guessing.

Limit the reach of your Remote Desktop availability

I’ve seen virtual local area networks (VLANs) being used more and more over the past years. Now, I see companies defining VLANs for servers, printers and desktops. VLANs for the desktops of systems administrators is not a very common practice yet.Through VLANs, access can be restricted to critical servers. For instance, using VLANs for critical servers and administrative personnel, you could limit TCP 3389 to these servers to administrators only.

If you’re not using VLANs, you can still achieve the same goal, through the use of the Windows Firewall and DHCP reservations.

DHCP reservations allow you to assign IP addresses to machines with specific MAC addresses. These addresses are Network Interface Card (NIC)-specific. Placing the desktops (and laptops) of systems administrators in a specific range of IP addresses, allows for Windows Firewall rules on other machines. (whether they’re servers or workstations). You can then limit access to Remote Desktop Services to IP adresses in the 192.168.1.x range, through the following command:

netsh advfirewall firewall set rule name="Remote Desktop (TCP-in)"
new remoteip=192.168.1.1-192.168.1.254

Alternatively you can use remoteip=192.168.1.0/24 to specify these computers.

If you’re using Remote Desktop on a webserver and you, as a systems administrator, manage it from a slew of IP addresses, limiting the reach of Remote Desktop Services through remote IPs is not really a good solution. In that case, securing Remote Desktop using IPSec, might be the way to go. Microsoft KnowledgeBase article 315055 explains it.

Alternatively, when your webserver already listens to IPv6 traffic, you might choose to enable the Remote Desktop Protocol to aNetwork Interface Card (NIC) assigned with an IPv6 address only. Within the Terminal Services Configuration snap-in (tsconfig.msc) on the Network Adapter tab of the RDP-Tcp properties you can select the Network Interface card from the list. Morto doesn’t scan for RDP on IPv6 addresses, yet.

Apply a centrally managed anti-malware solution

Many anti-malware vendors have added signatures for Morto.A and will add signatures for future versions of Morto when they get spotted in the wild. Even if the measures above seem inadequate or inappropriate to your situation, you might still be safe from most of the harm the Morto.A worm does, since the payload gets detected and removed when it first hits your environment. (most likely a managed desktop or laptop). An up to date anti-malware solution will prevent Morto.A from spreading and at the same time inform you of any (detected and removed) infections.

Apply a centrally managed Microsoft update solution

Since Morto.A uses an exploit to wreak havoc on your machines, it is sensible to patch the servers with critical updates fast. Fast, in this context, might mean hours, but in the case of a fully automated testbed for Microsoft updates, might also mean weeks. The rule of thumb here is to be quicker getting critical updates on your systems, than attackers are exploiting them.

Windows Server Update Services (WSUS) can be used free of charge, when you’re already using Windows Server. For more control or tested updates, Microsoft System Center Configuration Manager or Novell Patch Manager can be used. Although these two solutions cost a significant amount of money per managed desktop/laptop, they add significant benefits.

Concluding

To effectively defend against Win32/Morto.A, perform the following actions:

Apply a stringent and complete authentication policy
Deny Service Accounts to log on through Remote Desktop
Changing the usernames for well-known accounts
Apply an environment-wide Password Lockout policy
Report on invalid logon attempts through auditing
Limit the reach of your Remote Desktop availability
Apply a centrally managed anti-malware solution
Apply a centrally managed Microsoft update solution

This will provide a layered defense and adequate detection mechanisms. Don’t worry if you can’t perform all the above actions, you’ll be pretty safe given the circumstances.

Preventing OUs and Containers from Accidental Deletion

Sander Berkouwer — Wed, 13 Jul 2011 09:41:41 GMT

Those of you running Domain Controllers with full installations of Windows Server 2008 R2 or are managing Windows Server 2008 R2-based Domain Controllers using the Remote Server Administration Tools (RSAT) on Windows 7, might have seen the following configuration warning in the Active Directory Best Practice Analyzer (AD BPA):

About the Protect from Accidental Deletion functionality

In Active Directory, Organizational Units can be protected from accidental deletion (reads: using the del key in the wrong place at the wrong time). This way these objects cannot be deleted, unless the protection is removed. This Active Directory feature was first introduced in Windows Server 2008.

Organizational Units protected by default

Basically, according to the Microsoft best practices, All OUs in an Active Directory domain should be protected from accidental deletion. Unfortunately, however, after a clean install or an upgrade not all Organizational Units are protected:

Default OUs and containers
The default Organizational Units and containers are not protected by default:
- the Builtin container
- the Computers container
- the Domain Controllers Organizational Unit
- the ForeignSecurityPrincipals container
- the LostandFound container
- the Managed Service Accounts container
- the Program Data container and its underlying containers
- the System container and its underlying containers
- the Users container
- the NTDS Quotas container
Legacy OUs and containers
Only Organizational Units and Containers that were initially created using the Windows Server 2008, Windows Server 2008 R2, Windows Vista or Windows 7 Active Directory Users and Computers, Active Directory Administrative Center MMC Snap-ins or through the PowerShell Active Directory module are protected by default. (the option to Protect from Accidental Deletion is on by default in the dialog screen for creating an Organizational Unit)

Protecting Organizational Units

It is wise to protect all Organizational Units from accidental deletion. To search for unprotected Organizational Units, use the following two PowerShell commands:

Import-Module ActiveDirectory

Get-ADOrganizationalUnit -filter {name -like "*"} -Properties ProtectedFromAccidentalDeletion | format-table Name,ProtectedFromAccidentalDeletion

These commands will produce a table with two columns. The first column lists the names of the Organizational Units in the Active Directory environment. The second column uses true and false as answers to whether the Organization Unit is protected from accidental deletion or not.

In a clean Active Directory environment, typically, the Domain Controllers Organizational Unit would need the Protect object from accidental deletion property set to true to adhere to the Microsoft Best Practices. After you enable the Advanced Features from the View menu in Active Directory Users and Computers (dsa.msc), you can clearly see this on the Object tab of the OU:

Under the hood, what happens is:

the Delete Access Control Entries (ACEs) will be denied on the object itself
the Delete Child Access Control Entries (ACEs) will be denied on the parent object

To protect the Domain Controllers Organizational Unit (and any other unprotected Organizational Units), use the following two PowerShell commands:

Import-Module ActiveDirectory

Get-ADOrganizationalUnit -filter {name -like "*"} -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

Protecting containers

The Active Directory Best Practices Analyzer only checks the accidental deletion prevention on Organizational Units in an Active Directory environment, while the default containers might also contain important Active Directory objects.

Not to worry though, because accidentally deleting containers won’t a common occurrence:

In Active Directory Users and Computers and the Active Directory Administrative Console, you cannot create or delete containers. Also, pressing the Del key with a container selected has no effect. The commands are simply not present.
Although, in ADSI Edit (and other more direct Active Directory manipulation tools) the option to delete containers is more than present, using this option results in an error:

This is, in my opinion, the reason why the Active Directory Best Practices Analyzer doesn’t need to check the Protect from Accidental Deletion property on Active Directory containers and why, when checking with the Advanced Features turned on in Active Directory Users and Computers, these objects do not have the Protect from Accidental Deletion box selected.

Concluding

The Protect Organizational Units (OUs) from Accidental Deletion feature is a valuable addition to Active Directory. You will be notified through the Active Directory Best Practices Analyzer, when an Organizational Unit (OU) does not have this property set to true.

However, you will not receive a notice when containers are unprotected. The Active Directory Best Practices Analyzer does not check this. You don’t need to protect this kind of object, because other means are in place to keep you from (accidentally) deleting them.

How to add a DSRM startup option in Windows Server 2008 and Windows Server 2008 R2

Sander Berkouwer — Mon, 04 Jul 2011 12:03:18 GMT

Since Windows Server 2008, Microsoft no longer offers the ability to restart a Domain Controller in Directory Services Restore Mode (DSRM) from the default F8 boot menu.

About Directory Services Restore Mode

For Windows Server-based Domain Controllers, a special startup mode exists, where the Active Directory database isn’t loaded. This startup mode is called the Directory Services Restore Mode (DRSM). After logging in with the DSRM account, an admin can use this mode to troubleshoot Active Directory issues. The DSRM account does not live in Active Directory and its password is set on each Domain Controller. The password may, therefore, not be identical on all Domain Controller in the forest.

In Windows Server 2008 and Windows Server 2008 R2, several enhancements were made that affect the Directory Services Restore Mode:

Restartable Active Directory
Restartable Active Directory eliminates many of the reason to restart a Domain Controller in Directory Services Restore Mode (DSRM), with its capabilities to stop and start the Active Directory Domain Services. Reasons include offline defragmentation, However, restoring a previously made (system state) backup can only be performed within the Directory Services Restore Mode.
DSRM Admin Logon Behavior
When the Active Directory is stopped (through Restartable Active Directory) or not loaded (in Directory Services Restore Mode) you can use the DSRM password and Domain credentials to log in on the Domain Controller. The second option is only when other operational Domain Controllers exist in the domain. This behavior can be modified using the DSRMAdminLogonBehavior registry key, as described here.
Active Directory Recycle Bin
Directory Services Restore Mode is needed to restore objects in Active Directory from backup. The Active Directory Recycle Bin option in an all-Windows Server 2008 R2 forest, alleviates the need to use backups with built-in restore functionality.
Password syncing for the DSRM account
A feature is available for Windows Server 2008 that lets you synchronize the DSRM Administrator password with a domain user account. You can read more on this in Microsoft KnowledgeBase article 961320.

Default behavior in Windows Server 2008

According to this TechNet page, the procedure to access the Directory Services Restore Mode in Windows Server 2008 and Windows Server 2008 R2 is to either:

Use the System Configuration utility (msconfig.exe) and on the Boot tab select Safe Boot and specify the Active Directory repair option. Then restart.

Use the commandline: bcdedit /set safeboot dsrepair and restart. When done in Directory Services Restore Mode, type bcdedit /deletevalue safeboot and restart normally again.

When you’re deep in an undisclosed brown substance, however, these options are at least time consuming to perform. You can use the commandline when you choose to repair the Windows installation, but for this you’ll need to start from the Windows Server DVD, which might of might not be within reach, scratched or left in direct sunlight…

Adding the DSRM startup option

So, why not add the Directory Services Restore Mode startup option to the F8 boot menu as a default step after you’ve created a new Domain Controller? When you create a Domain Controller, normally, you’ll find some time to check its configuration, in contrast to the situation described earlier.

To add a Directory Services Restore Mode startup option to the Boot Configuration Database (BCD), perform the following commands:

bcdedit /copy {current} /d "Directory Services Restore Mode"

This command copies to current boot option ("Startup Normally") to a new startup option called "Directory Services Restore Mode". (If you want to use a different name, go ahead.)

Use the GUID from the above command, including the brackets) in the following command:

bcdedit /set {GUID} safeboot dsrepair

You’ve now added the startup option to the menu. If you want to make the Boot Menu visible by default every time the server (re)boots (instead of having to press F8), perform the following (optional) command, where you specify the seconds to display the menu:

bcdedit /timeout 5

In the example above, the menu gets displayed for five seconds. The result is a screen, every time you start or restart the Domain Controller, that will look something like this:

Concluding

I recommend every Active Directory administrator to perform the steps above to create a Directory Services Restore Mode (DSRM) startup entry. Whether you also specify a time-out by default is a choice, that depends on experience, your level of expertise, and your level of confidence.

Active Directory Feature Requirements

Sander Berkouwer — Mon, 06 Dec 2010 10:12:35 GMT

Microsoft has included numerous features in Active Directory the last couple of years. Also, more and more technologies in products like Exchange Server, SharePoint Server and the Windows client (Windows Vista, Windows 7) have an Active Directory opt-in to store information in Active Directory.

All this bountiful integration, however, comes with a price. The price in the case of Active Directory comes in three guises:

Operating System (OS) on the Active Directory Domain Controllers (DCs)
Active Directory Domain Functional Level
Active Directory Forest Functional Level

The table below shows the dependencies Active Directory features, like Group Policy Preferences, the Active Directory Best Practices Analyzer and Read-only Domain Controllers, and Active Directory opt-in technologies, like BitLocker Recovery Key Storage and DirectAccess, have in regards to the list above:

Red Not Available, Orange Required Set, Green Available, Grey Depends

¹	This feature requires the Group Policy Preferences Client Side Extensions on Windows clients. When no Windows Server 2008-based Domain Controllers are in use, the Group Policy Preferences need to be management from a workstation with at least Windows Vista SP1.( Windows 7 recommended)
²	For Windows Server 2003 and Windows Server 2008-based Domain Controllers the Active Directory Management Gateway Service needs to be installed. When no Windows Server 2008 R2-based Domain Controllers are in use, the management features can be accessed from a Windows 7 management workstation.
³	Managed Service Accounts (MSAs) are virtual domain accounts that can be used on Windows 7 and Windows Server 2008 R2 in Active Directory environments running Windows Server 2003 and Windows Server 2008 Functional levels. Domains at the Windows Server 2008 R2 functional level provide native support for both automatic password management and SPN management
⁴	In environments with multiple Domain Controllers, this feature requires the Domain Controllers participating in this feature to be installed with at least Windows Server 2008.
⁵	Enabled by default when an Active Directory domain is first setup using a Windows Server 2008 Domain Controller. Workaround available for Windows Server 2003-based Active Directory environments. (More info)
⁶	Enabled by default when an Active Directory domain is first setup using a Windows Server 2008 Domain Controller with the Windows Server 2008 Domain Functional Level. Requires a Sysvol FRS to DFS-R migration when migrating from a Windows Server 2003 environment. (More info)
⁷	Requires the BitLockerTPMSchemaExtension.ldf schema extension on Domain Controllers running Windows Server 2003. Also, all Domain Controllers need to be running at least Windows Server 2003 with ServicePack 1. (More info)
⁸	Requires at least one domain controller and DNS server that is running Windows Server 2008 SP2+ or Windows Server 2008 R2. When UAG is used, DirectAccess can be deployed with DNS servers and domain controllers that are running Windows Server 2003 when NAT64 functionality is enabled.

Active Directory Time Sync (broken by default)

Sander Berkouwer — Fri, 10 Sep 2010 11:03:00 GMT

Active Directory relies on accurate time for a number of reasons. One of this reasons is Kerberos authentication, which by nature can only cope with a difference in time (time skew) of five minutes between the Kerberos server and client.

Now, don’t get me wrong. I think the time skew limitation and the overall Kerberos implementation as we know it today, is fabulous. Keeping Domain Controllers up to date with a reliable time source (time sync) , however, is not as simple as you might expect it to be.

Time Sync in Active Directory

First of all, let’s look at the process of Time Sync in a default Active Directory environment:

Every Active Directory client (whether it’s a Windows client or a Windows Server) will synchronize it’s internal clock (time) with a Domain Controller.
Every Domain Controller synchronizes with the Domain Controller, holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role.
Since the PDCe FSMO role is a domain-wide operations role, a Domain Controller in an Active Directory subdomain will synchronize time with any Domain Controller in the forest root domain.

As you try to visualize this synchronization scheme, a sense of hierarchy should emerge. For this reason many people refer to this scheme as the Time Sync Hierarchy.

Challenges

The challenge with this hierarchy is the fact that any Domain Controller with a faulty internal clock (hardware) or faulty time synchronization (settings) can mess up a part of your Active Directory clients.

As described in blog post Active Directory in Hyper-V environments, Part 2, Time Sync between virtual Domain Controllers and the virtualization platform (through Integration Components/VMware tools) may attribute to this situation, where the virtualization platform does not synchronize time or synchronizes time with a different time source.

Broken by default

Not only may any Domain Controller on your environment cause time skew in a part of your environment. In the Active Directory Time Sync hierarchy a special place is reserved for the Domain Controller holding the PDCe FSMO role (in the Forest Root Domain).

Ideally, you want this server to synchronize time with a reliable time source. By default, however, this Domain Controller does not synchronize time, possibly time skewing your entire Active Directory forest.

Windows Server 2003

When you’re using Windows Server 2003 as your Domain Controller holding the PDCe FSMO role, it will by default synchronize time with time.windows.com. This host has proven to be less than reliable in the past. Anyone kicking off a manual time synchronization, might remember the screen below:

Windows Server 2008 & 2008 R2

Microsoft has decided to no longer synchronize time with a pre-defined time source from Windows Server 2008 onward. When you run the Active Directory Best Practices Analyzer, as described in blog post Server Manager in Windows Server 2008 R2, Part 3, you will receive an error on this default configuration, urging you to correct this situation:

Resolution

The resolution to this problem is to make sure:

Disable Time Synchronization between the virtualization platform and any virtual Domain Controller in the Integration Components/VMware tools
Enable Domain Controllers in your Forest Root Domain to communicate with NTP servers on the Internet through your corporate firewall. (UDP 123)
Manually configure the Domain Controller holding the Domain Controller, holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role in the Forest Root Domain with a reliable external time source,
- defining at least two different NTP servers by their Fully Qualified Domain Names (FQDNs)
- defining at least two different NTP servers by their IP addresses (to make sure Time Synchronization continues to work when DNS fails)

A viable command line to configure the Domain Controller would be:

w32tm /config /manualpeerlist: "europe.pool.ntp.org time.nist.gov 192.43.244.18 193.67.79.202"/syncfromflags:manual/reliable:yes/update

Considerations when upgrading your Active Directory to Windows Server 2008 and 2008 R2

Sander Berkouwer — Mon, 10 May 2010 00:15:49 GMT

While upgrading your Active Directory Domain Controllers, Domain Functional Level(s) and Forest Functional Level to Windows Server 2008 and Windows Server 2008 R2 offer additional functionality compared to previous versions, also a couple of caveats exist, that I think you should be aware of.

In this blogpost:

NT 4.0 Compatible Encryption
Going 64 (bit)
Getting acquainted with the Command-line
Limited ways to migrate to Windows Server 2008 R2
Deploying Server Core Domain Controllers
Virtualizing Domain Controllers

NT 4.0 Compatible Encryption

Windows Server 2008 and Windows Server 2008 R2 Domain Controllers have a new more secure default for the security settings named “Allow cryptographic algorithms compatible with Windows NT 4.0”.

When you promote a server to a Domain Controller, a screen containing this message is displayed, right after the Welcome screen:

This policy is configured to prevent Windows operating systems and third-party clients from using weak cryptography algorithms to establish NETLOGON security channels to Windows Server 2008-based domain controllers.

While this does not seem like a big deal, it might be in the light of the Active Directory Migration Tool (ADMT). Without the ability to build a trust between the source and target domain, one cannot migrate objects from a Windows NT4 domain. You never hope to encounter a Windows NT 4.0 environment in a merger, acquisition, or divestiture situation, but one can never be sure…

Also, you may experience problems in environments merely containing Windows Server 2008 and Windows Server 2008 R2 Domain Controllers when you configure pre-Windows Vista SP1 clients to join the domain though Windows Deployment Services or the Microsoft Deployment Toolkit (MDT). For Windows XP and Windows Server 2003 an update is available to correct this problem.

Now, of course, not migrating to Windows Server 2008 (R2) is a bit excessive. When you’re running into problems and don’t mind the loosened security settings, you can always (temporarily) turn on the “Allow cryptographic algorithms compatible with Windows NT 4.0” setting on every Windows Server 2008 and Windows Server 2008 R2 you need it. Perform the following steps:

Log on to a Windows Server 2008-based or Windows Server 2008 R2-based Domain Controller.
Click Start, click Run, type gpmc.msc, and then click OK.
In the Group Policy Management console, expand Forest: DomainName, expand DomainName, expand Domain Controllers, right-click Default Domain Controllers Policy, and then click Edit.
In the Group Policy Management Editor console, expand Computer Configuration, expand Policies, expand Administrative Templates, expand System, click Net Logon, and then double-click Allow cryptography algorithms compatible with Windows NT 4.0.
In the Properties dialog box, click the Enabled option, and then click OK.

After this step restart the netlogon service.

When you want to put the new default security settings into effect, perform the same steps, but click the Disabled option in step 5.

Going 64 (bit)

Windows Server 2008 R2 is only available in 64bit flavors. So, when transitioning from 32bit Domain Controllers to 64bit Domain Controllers, you’re bound to encounter some interesting challenges.

The first challenge is to prepare your Active Directory environment for Windows Server 2008 or Windows Server 2008 R2. To prepare an Active Directory environment for newer Domain Controllers, you’d run adprep.exe on the Domain Controller running the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role.

However, when preparing your 32bit Windows Server 2003 (R2) Active Directory environment for Windows Server 2008 x64-based Domain Controllers, you’d need to run the adprep.exe from the Windows Server 2008 x86 DVD. Luckily, the adprep.exe on the trial DVD will suffice for this purpose.

Preparing a 32bit Windows Server 2003 (R2) or Windows Server 2008 Active Directory environment for Windows Server 2008 R2 is a different story. You’ll need to run adprep32.exe in this case. It is located on the Windows Server 2008 R2 DVD in the same folder as adprep.exe. (This version of adprep.exe is x64 only.)

Also, when deploying Windows Server 2008 R2 Domain Controller, you should first check whether all the tools and programs you’re using in the current environment are 64bit- and Windows Server 2008 R2 ready. This includes anti-malware protection software, backup software, software for managing and responding to Uninterruptible Power Supply events, 3rd party management tools, and monitoring tools.

Getting acquainted with the Command-line

When migrating to Windows Server 2008 and Windows Server 2008 R2-based Domain Controllers and their respective Domain and Forest Functional Levels, prepare for some command-line stuff.

First off, to check for proper replication of the Active Directory preparation you can’t use the graphical replmon.exe tool. This tool is no longer available. Instead, you’ll need to use the command-line repadmin.exe tool.

Furthermore, most of the more advanced features, available when using Windows Server 2008 and Windows Server 2008 R2-based Domain Controllers and the Windows Server 2008 and Windows Server 2008 R2 Functional Levels, is only available on the command-line.

For instance, compacting your Active Directory database(s), managing fine-grained password policies, working with Active Directory snapshots, offline domain join, creating IFM media with SYSVOLs, enabling and using the Active Directory recycle bin and managing Managed Service Accounts (MSAs) is only available on the command-line (when using only built-in tools).

Read the series:

Limited ways to migrate to 2008 R2

While this blogpost was written, no suitable version of the Active Directory Migration Tool (ADMT) existed to restructure Active Directory environments to Windows Server 2008 R2.

Restructuring is one of three ways to migrate to a next version of Windows Servers as Domain Controllers. In-place upgrading and transitioning are the other two ways. With in-place upgrading a next version of Windows Server is used to upgrade a Domain Controller directly without reinstalling. Transitioning means adding additional Domain Controllers with a new version of Windows Server, side by side to existing Domain Controllers with the purpose of phasing out the old Domain Controllers.

When you want to restructure your Active Directory to Windows Server 2008 R2 you will either need to wait for the Active Directory Migration Tool (ADMT) version 3.2, or restructure to an Active Directory infrastructure, based upon Windows Server 2008 Domain Controllers and in-place upgrade or transition to Windows Server 2008 R2 Domain Controllers from there.

Deploying Server Core Domain Controllers

Server Core installations are optimized installations of Windows Server. This installation option was introduced with Windows Server 2008.

While Server Core Domain Controller are highly optimized, they also pose a problem when you’re mixing Windows Server 2008-based Server Core Domain Controllers, Windows Server 2008 R2-based Server Core Domain Controllers and the new Active Directory Administrative Center. (ADAC)

The Active Directory Administrative Center (ADAC) uses the Active Directory Web Service to communicate with Active Directory Domain Controllers. This service runs on top of the .Net framework.

The problem is Windows Server 2008-based Server Core Domain Controllers, don’t support the .Net framework. Therefore, you can’t use the Active Directory Administrative Center to manage these Domain Controllers. Of course, Windows Server 2008 R2-based Domain Controllers will still replicate changes, but your Domain Controllers will not be equal, which leads to a suboptimal management experience (over time).

Another difference between Server Core installations of Windows Server 2008 and Windows Server 2008 R2, is the different management tools available. Where Windows Server 2008 offers the ocsetup.exe and oclist.exe tools, Windows Server 2008 R2 offers dism.exe, which is more powerful.

Virtualizing Domain Controllers

Hyper-V is a new server role, introduced in Windows Server 2008. Along with Hyper-V, the Server Virtualization Validation Program (SVVP) came to life. Virtualization was already a hot topic in many enterprises by that time, but the popularity of virtualizing the datacenter rose further.

While virtualized Domain Controllers (whether they’re Server Core or Full installations) offer significant benefits in terms of flexibility, scalability and disaster recovery, they’re also the heart of the infrastructure and should be deployed wisely.

Therefore, follow these best practices when virtualizing Domain Controllers using Hyper-V clusters:

Deploy at least two Domain Controllers per domain and keep one physically deployed Domain Controller per domain;
Apply minimum patchlevels;
(specific hotfixes exist for Windows 2000 Server and Windows Server 2003)
Install the Integration components;
Provide adequate Time Synchronization;
Never save state or pause a Domain Controller;
Don't use undo disks, differencing disks or snapshots;
Backup and restore Domain Controllers the right way;
Use Fixed-Sized VHDs;
Use different disks for Active Directory files;
Use Sysprep.exe instead of NewSID.exe;
Don’t make your Domain Controllers highly available within Hyper-V;
(use Hyper-V R2 when you want to make your Domain Controllers highly available)
Secure your virtual Domain Controllers like you would physical Domain Controllers, but at a minimum use syskey.exe in virtualized Domain Controllers;
Perform Offline P2V Migrations when virtualizing an existing Domain Controllers;
Don’t perform storage migrations on live Domain Controllers.

Read the series:

Some Server Core Domain Controllers heading for a dead end street

Sander Berkouwer — Thu, 24 Sep 2009 12:15:12 GMT

You know, in terms of deploying servers in a smart way, so you can actually utilize them for as long as their economical lifecycle in a supported fashion without a need to reinstall them, I’ve made a stupid decision in advising IT Pros to deploy Server Core Domain Controllers in the last two years.

The problem, you see, is the product team responsible for Active Directory has made a design choice to leave the old world of RPC behind and to introduce a new way to manage Domain Controllers: using the Active Directory web service.

Windows Server 2008 R2 is the first Windows Server product featuring this new service, which besides the server component of the web service, also unlocks the usage of a whole load of other goodies like Active Directory PowerShell cmdlets and the Active Directory Administrative Center (ADAC). (when used from a Windows 7 or Windows Server 2008 R2-based management box)

While the decision was made a while ago, only now do I realize the impact. Now that Microsoft released the Active Directory Management Gateway Service (Active Directory Web Service for Windows Server 2003 and Windows Server 2008) and both Jorge and Tomasz blogged about it. This Stand-alone Update Package basically adds the Active Directory Web Services service to Domain Controllers, running:

Windows Server 2003 with Service Pack 2
Windows Server 2003 R2 with Service Pack 2
Windows Server 2008
Windows Server 2008 with Service Pack 2

Except there’s one problem: .Net Framework 3.5 with Service Pack 1 (SP1) is required. Whoops! That’s not exactly available on Server Core installations of Windows Server 2008 in a supported fashion.

As a consequence Windows Server 2008-based Server Core Domain Controllers can not be used in combination with the Active Directory PowerShell cmdlets and the the Active Directory Administrative Center (ADAC).

Note:
Windows Server 2008 R2-based Server Core Domain Controllers, however, can be managed using the Active Directory PowerShell cmdlets and the Active Directory Administrative Center (ADAC). One of the new features of Server Core installations in Windows Server 2008 R2 is the availability of the .Net Framework.

Actually when you try to install the Active Directory Management Gateway Service on a Windows Server 2008-based Server Core Domain Controller a check is performed upon your system.

Server Core installations fail the check. The result is an error stating “The update does not apply to your system” as shown above on a x64 Server Core installation of Windows Server 2008 (OperatingSKU 13). This box was setup as a Domain Controller and configured with the Primary Domain Controller emulator (PDCe) FSMO role (DomainRole 5).

Concluding

When running an environment with Windows Server 2008-based Server Core Domain Controllers, a requirement to use the Active Directory PowerShell cmdlets or Active Directory Administrative Center (ADAC) implicates the need to reinstall the Windows Server 2008-based Server Core Domain Controllers as Full installations or the need to upgrade the Windows Server 2008-based Server Core Domain Controllers to Windows Server 2008 R2-based Server Core Domain Controllers.

(Web)Press review
Active Directory Gateway WebService is available for ‘legacy’ OSes
How to tell whether it’s a Server Core Domain Controller
How to tell whether it's a Server Core box

How to tell whether it’s a Server Core Domain Controller

Sander Berkouwer — Wed, 23 Sep 2009 11:52:51 GMT

Server Core installations of Windows Server 2008 can be utilized in a variety of ways. I’ve written about using them as Web 2.0 Servers with IIS 7, PHP and MySQL, as Streaming media (reverse) proxies, as branch office servers, loaded with DFS, DNS, DHCP and secured with BitLocker Drive Encryption and of course using them as highly-optimized Active Directory Domain Controllers.

But, how exactly do you tell whether a Server Core box is a Domain Controller?

The command to check this is actually surprisingly simple:

wmic.exe ComputerSystem get DomainRole

But the output is puzzling, to say the least…

In the screenshot above the command returns a numeric value.

Again, just like when you want to find out what edition of Windows Server you’re running, deciphering the value to something that makes sense to humans is key to get the info.

The table to use to decipher the DomainRole value can be found on the MSDN page of the ComputerSystem class:

Value	Hexidecimal value	DomainRole
0	0x0	Standalone Workstation
1	0x1	Member Workstation
2	0c2	Standalone Server
3	0x3	Member Server
4	0x4	Backup Domain Controller
5	0x5	Primary Domain Controller

In the screenshot above the returned value is 5, which means the Server Core installation is, in fact, a Domain Controller. Not just a Domain Controller though… It’s the Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role.

Concluding

Using the DomainRole property of the ComputerSystem class is a useful and fast way to check whether a Server Core installation of Windows Server is a Domain Controller, whether it’s domain-joined and whether it holds the PDCe FSMO role.

How to tell whether it's a Server Core box
SC'enario: The Kitchen Cupboard Server
SC'enario: Streaming Media (reverse) Proxy
SC'enario: Windows Web 2.0 Server 2008

The things that are better left unspoken : Microsoft Windows Server 2008, Active Directory

Active Directory Services and their System Center Management Packs

Active Directory Domain Services

Active Directory Lightweight Directory Services

Active Directory Certificate Services

Active Directory Federation Services

Active Directory Rights Management Services

Related blogposts

Further reading

Related downloads

Active Directory Services on Server Core installations

Related blogposts

Further reading

KnowledgeBase: You cannot use redirusr.exe and redircmp.exe in the Windows Server 2008 DFL on Windows Server 2008

A short history on redirusr.exe and redircmp.exe

Using redirusr.exe and redircmp.exe

Now for the bug…

The workaround

Further reading

MS013-032 Vulnerability in Active Directory Could Allow Remote Code Execution (Important)

Affected Operating Systems

Guidance

Related Posts

Further reading

PowerShell, LDIFDE, CSVDE and Protection from Accidental Deletion

Concluding

Related Posts

Further reading

Active Directory in Hyper-V environments, Part 7

In this series

Related KnowledgeBase articles

Further reading

Tipjar

DCPROMO Advanced Mode, what does it do?

Windows 2000 Server

Configure your Server wizard

Dcpromo.exe

Windows Server 2003 & 2003 R2

New Domain Controller for a new forest

New Domain Controller for an existing domain/forest

Windows Server 2008 & 2008 R2

New Domain Controller for a new forest

New Domain Controller for an existing domain/forest

Concluding

How to effectively defend against Morto.A in the enterprise

About Win32/Morto.A

The problem

Defending against Morto.A

Apply a stringent and complete authentication policy

Secure Service Accounts

Change the usernames for well-known accounts

Apply an environment-wide Password Lockout policy

Report on invalid logon attempts through auditing

Limit the reach of your Remote Desktop availability

Apply a centrally managed anti-malware solution

Apply a centrally managed Microsoft update solution

Concluding

Preventing OUs and Containers from Accidental Deletion

About the Protect from Accidental Deletion functionality

Organizational Units protected by default

Protecting Organizational Units

Protecting containers

Concluding

How to add a DSRM startup option in Windows Server 2008 and Windows Server 2008 R2

About Directory Services Restore Mode

Default behavior in Windows Server 2008

Adding the DSRM startup option

Concluding

Other DirTeam posts on this topic

Further reading

Active Directory Feature Requirements

Active Directory Time Sync (broken by default)

Time Sync in Active Directory

Challenges

Broken by default

Windows Server 2003

Windows Server 2008 & 2008 R2

Resolution

Further reading

Considerations when upgrading your Active Directory to Windows Server 2008 and 2008 R2