Upgrade Active Directory to Windows Server 2012 - Phase 1: Assessment

Doug Symalla and Greg Jaworski here, tag-teaming to give you a hefty blog, full of detail.

In Doug's last blog, he laid out an Active Directory upgrade roadmap. We promised you some practical detail for each of the phases, so let’s get started with the first phase– the Assessment. The goal of this blog is to give you in-depth details on what information you should collect, why you should collect it and how you can collect it. Keep in mind you will never have perfect information, and there will always be gaps. You need to decide when the cost of gathering more information exceeds its potential benefits. If you have some suggestions on what, how or why for gathering more information please let us know in the comments. We always welcome your feedback.

Document Your Current AD Architecture, DC sizing and DC Placement

What: A concise view of your entire infrastructure. This includes AD Sites, Site Links, Domain Controller placement, Domain Controller Sizing and baseline Performance data.

Why: You will eventually need to decide (see Planning Phase) if you are going to simply replace all of your existing (old) domain controllers with new ones, or if you will redesign/resize your infrastructure.

How:

· Draw a map with the AD Topology Diagrammer. The AD sites and AD domains diagrams are the important components. Pay attention, as well, to domain/forest functional levels and trust relationships with other domains/forests.

· For every DC collect some basic build/configuration data. This should include OS, amount of memory, CPUs, disk size(s), and layout. Draw on your PowerShell mojo to programmatically collect and collate this information across all of your DCs.

· Collect Some Baseline Performance Data. Use Perfmon. Stick to the basics:

o CPU utilization
o Memory utilization
o LSASS.exe working set and LSASS CPU utilization
o For each disk – average disk sec/read and average disk sec/write
o LDAP searches per sec
o LDAP bind times
o NTLM authorizations per sec
o Kerberos authorizations per sec

Inventory Non-Default Domain Controller Configuration

What: Details on your Domain Controller configuration – specifically, non-default configurations.

Why: You need to decide if/how you are going to retain this configuration moving forward.

How: Dig around the registry, group policies and AD Database.

· Check for the following settings in the registry on your Domain Controllers (another good use for PowerShell). Then, use Group Policy Modeling or Group Policy results to see which configuration is being delivered through policy and which is manual.

o Look for the use of static RPC ports. For example, are you fixing the RPC port range, the FRS port or AD Replication ports?

o Did you disable SMB signing once upon a time ago?

o Are you deploying/installing certificates (for LDAPs) on your domain controllers?

o Have you changed the default LMCompatibilityLevel?

o Did you disable eDNS when you deployed your 2003 Domain Controllers, or anytime thereafter?

o Have you modified the limits on NSPI connections?

o Did you enable DES encryption after you discovered it was disabled by default in Windows 7/2008 R2?

· Check for the following settings in your AD database:

o Have you modified the default LDAP query policy?

o Do you have any user accounts in the directory that have been configured to use DES encryption?

Inventory Other Applications/Services Running on Your DCs

What: Determine other services/applications installed on your Domain Controllers.

Why: Before you retire a Domain Controller, you might need to account for/migrate other services such as DHCP, WINS or DNS.

How:

Analyze the services and programs installed on your DCs (another good use for PowerShell). Determine which of them need to be migrated either to new Domain Controllers or elsewhere. Some of the relatively common services/applications we’ve seen running on Domain Controllers that may be overlooked include:

· DHCP
· DNS
· WINS
· Terminal Services Licensing
· DFS Namespaces (other than SYSVOL)
· Certificate Services
· IAS/Radius/NPS
· Directory Sync/Password Sync agents
· Custom Password Filters

Research and Document Your AD Dependents

What: Inventory your Active Directory Dependents.

Why: You need to research whether or not your dependents are compatible with the new version of Active Directory/Domain Controllers.

How:

Depending on the size of your environment, this could be a big task. It’s likely you have applications/clients that use Active Directory of which you are not even aware. So I would recommend you start with:

1. Known/Obvious Dependents

2. Critical Business Applications (and other dependents)

Known/Obvious Dependents:

· Start with computers/clients that are domain integrated. Query every computer object for the Operating System attribute. Look for unsupported Microsoft Operating Systems, such as Windows NT or Windows 2000. For non-Microsoft operating systems, research compatibility with the OS vendor.

· Consider common Microsoft Applications, such as Exchange or SCCM. In some cases the application might run on your Domain Controller (an SCCM agent, for example) while in other cases the application may depend on AD. Start here to research compatibility.

· Document and research compatibility for any other known dependents. This could include, for example, other directory services that integrate/sync with AD or LDAP applications that pull data from AD. Be sure to note whether the application “discovers” domain controllers, or whether you need to configure the application with IP addresses and/or names of domain controllers. If it’s the latter, you’ll have to remember to update the configuration with new hostnames/IP addresses as the new Domain Controllers come on-line.

Critical Business Applications and Other Dependents

· Let the hunting begin. You need to track down other dependents, and research the potential impact of an upgrade. Start with the critical/important systems that run the business. Determine if/how they integrate with AD, then research compatibility with new(er) versions of domain controllers.

· If you’re really brave, you can enable verbose LDAP logging and/or verbose Netlogon logging on your DCs, sift through all the noise and see if you can find any “interesting” dependents. Please proceed with caution before exploring these paths. If you’re not careful, you may generate a lot of noise (and headaches) without gaining any useful information.

· Another interesting option (again I’ll warn you that the degree of difficulty is high) would be to specifically hunt down legacy LM/NTLMv1 clients. Our colleagues at AskDS have a great blog on this topic.

Research Changes to Default OS/DC Behavior and Potential Impact

Much of the information we’ve asked you to collect, above, provides hints to some of the changes in the default behavior of newer Windows OS versions. Immediately following is a table/cheat sheet summarizing these changes. Thereafter is a more detailed description for these items, how they might impact you, our recommendation and potential workarounds. Note: We didn’t include unexpected behaviors/errors that may come when upgrading. You can find those here. They should be researched during your planning/testing phases.

We’ve included this table, and an abbreviated description for all these issues in an Excel spreadsheet. We’re hoping it may prove as a nice tactical tool for you. You can find the spreadsheet here.

The LM Hash and LM Authentication:

Starting with Windows Server 2008, domain controllers (and domain members) will no longer store the LM hash for passwords. These hashes are easily cracked to reveal passwords. Additionally, LM authentication will no longer be possible.

Recommendations:
Adopt the new default behavior, and stop storing the LMHash for passwords. It’s much more secure, and any legacy clients/applications that need to use LM authentication need to be upgraded/removed.

References:
http://support.microsoft.com/?id=299656
http://support.microsoft.com/?id=946405

NT 4.0 Cryptography Algorithms and NT 4.0 Trusts:

Beginning with Windows Server 2008, the operating system stopped using “legacy” cryptography algorithms for secure channel communications. By default, Windows NT 4.0 (and other applications/OS’s that use this algorithm) will not be able to establish a secure channel (or otherwise authenticate) with a Windows Server 2008, or higher, domain controller. There is a configuration setting/GPO that can reverse this behavior – “Allow cryptography algorithms compatible with Windows NT 4.0”. Be warned; however, that even this configuration option will not allow Windows Server 2008 R2 and NT 4.0 to work across a trust relationship.

Recommendations:
This one is relatively simple, mostly because we (Microsoft) don’t support NT 4.0 anymore. So the best recommendation is to get away from NT 4.0. Stop wasting time/resources trying to drag it into the modern world. If you must run it, get it out of the domain, disconnect it from the internet and do whatever you can to isolate it so it can die a peaceful death.

References:
http://support.microsoft.com/kb/942564
http://support.microsoft.com/kb/2021766

DES Encryption and Kerberos Authentication:

Starting with Windows Server 2008 R2, domain controllers (and domain members) will no longer allow DES encryption for Kerberos tickets. DES encryption was cracked last millennium, so it’s time to move on to better encryption mechanisms like AES.

Recommendations:
Collect data to determine who/what still uses DES encryption in the domain. Either upgrade/eliminate the offender. If you must, it is possible to configure 2008 R2 and higher domain controllers to allow DES encryption for Kerberos.

References:
http://support.microsoft.com/kb/978055

AES Encryption and Kerberos Authentication:

AES encryption support for Kerberos was added, beginning with Windows Server 2008 and Windows Vista. While this is a good thing, you may notice event logs on your down-level clients complaining about an unsupported encryption type. No need to worry, because clients/DCs will negotiate the proper encryption type.

Recommendations:
No action is required. Be aware that down-level clients will not support the new encryption types, and may log warnings/errors in their security event log.

References:
http://technet.microsoft.com/en-us/library/cc749438(v=WS.10).aspx

Limits to LDAP Query Policies:

Beginning with Windows Server 2008, hardcoded limits to LDAP policies have been implemented. These limits are significantly more aggressive than the configurable range in Windows Server 2003. Specifically, MaxReceiveBuffer, MaxPageSize,MaxQueryDuration,MaxTempTableSize and MaxValRange have been capped. So if you have configured these parameters to be significantly different from the default, you may run into these hard limits.

Recommendations:
Evaluate your current configuration for LDAP query policy. If it’s default, you have nothing to worry about. If you’ve modified it, be sure it doesn’t exceed these new hard limits. If it does, determine why and what you can do about the offending client/application.

References:
http://support.microsoft.com/default.aspx?scid=kb;en-US;2009267

Limits to NSPI connections:

The Name Server Provider Interface (NSPI) is an interface provided by domain controllers to allow messaging clients to access and manipulate address book data. Beginning with Windows Server 2008, the number of concurrent NSPI connections was limited to 50 connections per user, per DC. This behavior was changed to protect DCs from resource exhaustion in the scenario when NSPI clients continuously open without closing unneeded connections. Some messaging applications use a service account to perform NSPI connections on behalf of users. In this scenario, a single user account can open hundreds or thousands of NSPI connections to a single DC under the context of a single user. In this case, it may be necessary to increase the maximum number of NSPI connections on 2008 R2 domain controllers.

Recommendations:
If you have a messaging client/application that requires more than 50 concurrent NSPI connections per user/service account, you can modify this default limit. Estimate a more appropriate value (something between the Server 2008 default of 50 and the Server 2003 default of 4 billion), and configure your domain controllers with this value.

References:
http://support.microsoft.com/kb/949469

SMB Signing:

SMB signing has been around for a while. Microsoft operating systems since Windows NT 4.0 SP3 have been capable of SMB signing. It was enabled by default since Windows Server 2003. So if you disabled this setting once-upon-a-time, now is a good time to re-enable.

Recommendations:
Review your current configuration for SMB signing – specifically, if it has been disabled. If so, determine why and if you can now re-enable this security-related setting.

References:
http://support.microsoft.com/kb/887429

Computer Browser Service:

Windows Server 2008 and beyond disable the computer browser service by default. This seems relatively harmless (and a good idea); however, be aware that the “My Network Places” or “Network Neighborhood” rely on the computer browser.

Recommendations:
Unless you have a good reason, go ahead and disable the computer browser service.

References:
http://technet.microsoft.com/en-us/library/bb726965.aspx

Default LMCompatibilityLevel:

The LMCompatibilityLevel can be configured from 0 to 5. Windows Server 2003 defaults to LMCompatibilityLevel 2, while Windows Server 2008 and higher default to LMCompatibilityLevel 3. Thus, Windows Server 2008 domain controllers (and higher) will continue to accept the same NTLM authentication levels (LM,NTLM,NTLMv2) as Windows Server 2003 domain controllers. However, when acting as a client, Windows Server 2008 (and higher) will use NTLMv2 (not NTLMv1). This is different than Windows Server 2003 when acting as a client, which will use LM or NTLM (v1 or v2). Thus, the server-side behavior will not change, while the client side behavior will change.

Recommendations:
Read the reference, below, for a good understanding of how NTLM authentication works. This will help understand the implications of moving from a default setting of 2 to a default setting of 3. Then, determine what setting you currently use (default or otherwise). Finally, determine what setting you wish to achieve (the new default or otherwise).

References:
http://technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx

DFS Site-Costed Referrals:

Windows Server 2008 and higher domain controllers enable DFS site-costed referrals by default. This allows DFS clients to locate targets (including SYSVOL and NETLOGON) closest to the client, sorted by cost as defined on AD site-links. Windows Server 2003 domains controllers sort referrals in a more random (and less efficient) fashion.

Recommendations:
Adopt the new default configuration, with site-costed referrals enabled. If up level domain controllers will co-exist for a period of time with Windows Server 2003 domain controllers, consider enabling the Site-Costed Referrals setting on the Windows Server 2003 DCs.

References:
http://support.microsoft.com/kb/905846

Null Session Pipes and Null Session Shares:

The default list of exceptions in Windows Server 2003 included anonymous access to named pipes for (amongst others) Systems Network Architecture (SNA), print spooler, browser, netlogon, lsarpc and Security Account Manager (SAMR). These exceptions were allowed for backwards compatibility with legacy clients and applications. In Windows Server 2008 R2 the default list for NullSessionPipes is shorter (only 3 entries), and the default NullSessionShares list is empty. It is possible that this could cause problems for legacy clients/applications that still rely on null session access to the domain controller across specific named pipes and/or shares

Recommendations:
It’s not likely you have clients that require null session pipe/share access. If you do, it’s not likely you know which clients. Test where possible. Otherwise, just be aware of the change and accept it. If you discover a problem, you can roll this change back.

References:
http://technet.microsoft.com/en-us/library/dd162275.aspx
http://msdn.microsoft.com/en-us/library/aa365590(VS.85).aspx

EDNS0:

Extension Mechanisms for DNS (EDNS0) functionality permits the use of larger User Datagram Protocol (UDP) packet sizes. However, some firewall programs may not permit UDP packets that are larger than 512 bytes. As a result, these DNS packets may be blocked by the firewall. Technically EDNS0 was enabled in Server 2003; however some customers disabled its behavior. You’ll want to investigate whether your current DCs/DNS servers have EDNS0 enabled or disabled.

Recommendations:
Leave EDNS0 enabled. If necessary, configure the firewall/network device to permit UDP packets that are larger than 512 bytes. If necessary, the EDNS0 behavior can be disabled.

References:
http://support.microsoft.com/kb/828263
http://support.microsoft.com/kb/832223

LDAP Behavior:

Windows Server 2008 R2 and Windows Server 2012 Domain Controllers are stricter in regards to compliance with RFC2696 Section 3. Specifically, when performing a paged query, each page of a query must contain identical values with the exception of the messageID, cookie, and optionally a modified pageSize. If the pages of the queries are not properly formed, DCs will return an error UNAVAIL_EXTENSION instead of the requested page. Windows Server 2003 and Windows Server 2008 DCs do not enforce this.

Recommendations:
The affected LDAP application/query should be updated/modified to perform an RFC2696 compliant query. If this is not possible, the behavior change on the DCs can be reverted back to Server 2003 behavior.

References:
http://support.microsoft.com/kb/2468316
http://support.microsoft.com/kb/977180

SID Compression:

Kerberos authentication in Windows includes access tokens (a user’s SID, plus SIDs from groups which they are a member of, plus SID history…) in the authentication data portion of Kerberos tickets. If an access token is too large, the authentication data may not fit into the Kerberos ticket. To help reduce the size of the authentication data, Windows Server 2012 domain controllers will compress SIDs, by default. Other third-party Kerberos clients may not understand the authentication data with the compressed SIDs.

Recommendations:
Research non-Windows Kerberos clients to determine if they are compatible with SID compression. If not, this default behavior for Windows Server 2012 DCs can be disabled.

References:
http://support.microsoft.com/kb/2774190
http://blogs.technet.com/b/askds/archive/2012/09/12/maxtokensize-and-windows-8-and-windows-server-2012.aspx

Dynamic RPC Port Range:

To comply with Internet Assigned Numbers Authority (IANA) recommendations, Microsoft changed the dynamic client port range for outgoing connections beginning in Windows Vista and in Windows Server 2008. The new default start port is 49152, and the default end port is 65535. This is a change from the configuration of earlier versions of Windows that used a default port range of 1025 through 5000.

This change is not related to Active Directory Services, however Active Directory uses RPC for communication so is therefore affected by this change.

Recommendations:
Be aware of the changes in RPC behavior. If DCs communicate (replicate AD and FRS) through a firewall, ensure the firewalls are configured to allow this new port range.

References:
http://support.microsoft.com/kb/929851
http://support.microsoft.com/kb/832017

I hope you appreciate the effort we put into this,

Greg “AD Upgrade Ninja” Jaworski

Doug “Out of Blogging Breath“ Symalla