AD Reading: Active Directory Database

The following are extremely useful resources for understanding the Active Directory Database.

AD Database

o   Data Store Architecture

o   Data Store Protocols

o   Data Store Interfaces

o   Data Store Logical Structure

o   Data Store Physical Structure

o   Data Store Processes and Interactions

o   Network Ports Used by the Data Store

o   Related Information

o   Directory Tree

o   Storage Limits

o   Directory Data Store

o   Object-Based Security

o   Growth Estimates for Active Directory Users and Organizational Units

o   Data Characteristics

o   Windows 2000 SAM Storage

o   Data Model

o   Container Objects and Leaf Objects

o   Directory Partitions

o   Transaction Log Files

o   Temporary Transaction Log Files

o   Reserved Transaction Log Files

o   Checkpoint Files

o   Database Files

o   Temporary Databases

AD Reading: Active Directory Core Concepts

The following are extremely useful resources for understanding Active Directory Core Concepts.

Core Directory Concepts & Key Items

o   Attributes

o   Containers and Leaves

o   Object Names and Identities

o   Naming Contexts and Directory Partitions

o   Domain Trees

o   Forests

o   Active Directory Servers and Dynamic DNS

o   Replication and Data Integrity

o   Active Directory Logical Structure

o   Active Directory Data Storage

o   Name Resolution in Active Directory

o   Active Directory Schema

o   Service Publication in Active Directory

o   Active Directory Replication

o   Managing Flexible Single-Master Operations

o   Monitoring Performance in Active Directory

o   Active Directory Backup and Restore

o   Active Directory Diagnostics, Troubleshooting, and Recovery

o   Active Directory on a Windows Server Network

o   Active Directory Application Mode

o   Structure and Storage Technologies

o   Domain Controller Roles

o   Replication Technologies

o   Search and Publication Technologies

o   Installation, Upgrade, and Migration Technologies

o   Introduction

o   Active Directory User and Computer Accounts

o   Active Directory Groups User Authentication

o   User Authorization

o   Summary

o   Appendix A: Built-in, Predefined, and Special Groups

o   Appendix B: User Rights

o   Understanding AD DS Design

o   Identifying Your AD DS Design and Deployment Requirements

o   Mapping Your Requirements to an AD DS Deployment Strategy

o   Designing the Logical Structure for Windows Server 2008 AD DS

o   Designing the Site Topology for Windows Server 2008 AD DS

o   Enabling Advanced Features for AD DS

o   Evaluating AD DS Deployment Strategy Examples

o   Appendix A: Reviewing Key AD DS Terms

o   Active Directory Logical Structure

o   Active Directory Data Storage

o   Name Resolution in Active Directory

o   Active Directory Schema

o   Service Publication in Active Directory

o   Active Directory Replication

o   Managing Flexible Single-Master Operations

o   Monitoring Performance in Active Directory

o   Active Directory Backup and Restore

o   Active Directory Diagnostics, Troubleshooting, and Recovery

o   What Are Domain and Forest Trusts?

o   How Domain and Forest Trusts Work

o   Domain and Forest Trust Tools and Settings

o   Security Considerations for Trusts

o   What Is the Global Catalog?

o   How the Global Catalog Works

o   Global Catalog Tools and Settings

o   What are Operations Masters?

o   How Operations Masters Work

o   Operations Masters Tools and Settings

o   What Is TCP/IP?

o   How TCP/IP Works

o   TCP/IP Tools and Settings

o   Planning Deployment of AD DS in the Perimeter Network

o   Designing RODCs in the Perimeter Network

o   Deploying RODCs in the Perimeter Network

o   Planning to Virtualize Domain Controllers

o   Deployment Considerations for Virtualized Domain Controllers

o   Operational Considerations for Virtualized Domain Controllers

o   Backup and Restore Considerations for Virtualized Domain Controllers

o   USN and USN Rollback




Hyper-V 2012 Resources

I have been researching Hyper-V 2012 quite a bit over the past couple of months. Here are some of the more useful links:

Intel vPro Technology Security

In every modern (recent) Intel processor, there is a remote access

Hardware Secrets posted:

Intel’s vPro technology provides IT managers with a collection of security and manageability features, including remote access to the PC independent of the state of the operating system or that of the computer’s power. The newest vPro processors include an identity protection technology with public key infrastructure (Intel IPT with PKI), which provides a new second layer of authentication embedded into the PC that allows websites and business networks to validate that a legitimate user is logging on from a trusted PC by using a private key stored in a PC’s firmware. In addition, the chipset has Intel’s Secure Key, a hardware-based random number generator that businesses can use to encrypt applications, OS Guard malware detection and prevention technology, and McAfee ePolicy Orchestrator (ePO) Deep Command, which is designed to allow remote patching.

Intel’s website provides more details.

KMS Part 2

This is an addendum post to the original KMS info post with a bunch of useful info I gathered recently.

Useful KMS and Windows activation commands:

Change Windows 2008 R2 license key type from Retail to KMS activated:
Slmgr /ipk 489J6-VHDMP-X63PK-3K798-CPX3Y

Clear cached KMS host:
Slmgr.vbs /ckms

Disable KMS host caching:
Slmgr.vbs /ckhc

Flush local system DNS cache:
Slmgr.vbs /flushdns

Force immediate activation:
Slmgr.vbs /ato

Enable KMS Host caching:
Slmgr.vbs /skhc

Point activation to a specific KMS Server (disables KMS autodiscovery via DNS):
Slmgr.vbs /skms:SERVER

Display detailed license information (& KMS Host Info):
Slmgr.vbs /dlv

Get information about OS activation from KMS Server:
slmgr.vbs / dli

Configure a server to run KMS:

Install the KMS activation key by running the following:
slmgr.vbs /ipk <KMS Activation Key>

Run the following command to immediately activate:
slmgr.vbs /ato

Restart the Software Licensing Service (SPPSVC):
net stop sppsvc && net start sppsvc

The Software Licensing Service (SPPSVC) handles registration of the DNS service (sRV) record which is created in the same DNS domain the KMS host is installed uder the _tcp subzone.

KMS will automatically handle activations for systems in the same DNS Domain.  In order to expand the scope to other domains, a registry hack is required.

Open Regedit and navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform
Create a new Multi-String key called DnsDomainPublishList

Edit the key and add each additional DNS domain suffic that KMS should publish to on a separate line.
Restart the Software Licensing Service (SPPSVC):
net stop sppsvc && net start sppsvc

If Dynamic DNS is not enabled for your AD domain, you will have to manually add the SRV record for KMS with ths following information:
Service: _VLMCS
Protocol: _TCP
Port Number: 1688

Note: Only the first KMS Host can create an SRV record – subsequent KMS Hosts cannot change or update SRV records unless the default DNS permissions are modified.

Configuring KMS Clients:

Manually specify a KMS Host:
slmgr.vbs /skms <value>:<port>

NOTE: When you manually specify a KMS host, this disables automatic discovery of the KMS host.

Enable Auto-discovery:
slmgr.vbs /ckms

Change a client from retail to volume activation:
Slmgr.vbs /ipk <SetupKey>

Change a client registered with a MAK key to KMS:
slmgr.vbs /ipk <KmsSetupKey>

KMS Setup Keys:

Windows 7 Professional:  FJ82H-XT6CR-J8D7P-XQJJ2-GPDD4
Windows 7 Professional N:  MRPKT-YTG23-K7D7T-X2JMM-QY7MG
Windows 7 Enterprise:  33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
Windows 7 Enterprise N:  YDRBP-3D83W-TY26F-D46B2-XCKRJ
Windows 7 Enterprise E:  C29WB-22CC8-VJ326-GHFJW-H9DH4

Windows Server 2008 R2 HPC Edition:  FKJQ8-TMCVP-FRMR7-4WR42-3JCD7
Windows Server 2008 R2 Datacenter:  74YFP-3QFB3-KQT8W-PMXWJ-7M648
Windows Server 2008 R2 Enterprise:  489J6-VHDMP-X63PK-3K798-CPX3Y
Windows Server 2008 R2 for Itanium-Based Systems:  GT63C-RJFQ3-4GMB6-BRFB9-CB83V
Windows Server 2008 R2 Standard:  YC6KT-GKW9T-YTKYR-T4X34-R7VHC
Windows Web Server 2008 R2:  6TPJF-RBVHG-WBW2R-86QPH-6RTM4


Security Considerations for Active Directory (AD) Trusts


TechNet has an article on the Security Considerations for Active Directory (AD) Trusts.

This is a must read to fully understand the issues with the security implications of trust configurations.

  • Potential Threats to Interforest Trusts
  • Security Settings for Interforest Trusts
  • Minimum Administrative Credentials for Securing Trusts
  • Trust Security and Other Windows Technologies

Related Information

The threat scenarios outlined in this section apply only to trusts made between two forests (also known as interforest trusts), including external and forest trusts. All other trusts made within a forest (also known as intraforest trusts), including parent-child, tree-root, and shortcut trusts, are optimally secured by default and do not require further planning to mitigate any known threat. As with intraforest trusts, there are no known threats to realm trusts that require mitigation.

You should be familiar with these threats before you deploy or configure a Windows Server 2003 network environment.
Potential Threats to Interforest Trusts

There are two potential threats to interforest trust relationships in Windows Server 2003. These threats can disrupt or undermine the integrity of interforest trusts.

Attack on trusting forest by malicious user in a trusted forest. A malicious user with administrative credentials who is located in a trusted forest could monitor network authentication requests from the trusting forest to obtain the security ID (SID) information of a user who has full access to resources in the trusting forest, such as a Domain or Enterprise Administrator. SID filtering is set on all trusts by default to help prevent malicious users from succeeding with this form of attack. For more information about how SID filtering works, see “Security Settings for Interforest Trusts.”

Attack on shared resources in a trusting forest by malicious users in another organization’s forest. Creating an external or forest trust between two forests essentially provides a pathway for authentications to travel from the trusted forest to the trusting forest. While this action by itself does not necessarily create a threat to either forest, because it allows all secured communications to occur over the pathway, it creates a larger surface of attack for any malicious user located in a trusted forest. Selective authentication can be set on interforest trusts to help minimize this attack surface area. For more information about how to mitigate this threat, see “Security Settings for Interforest Trusts.”

Security Settings for Interforest Trusts

There are two security settings in Windows Server 2003 that can be used to enhance the integrity of communications made over interforest trusts. SID filtering helps prevent malicious users with administrative credentials in a trusted forest from taking control of a trusting forest. Selective authentication lessens the attack surface by restricting the quantity of authentication requests that can pass through an interforest trust.
SID Filtering

SID filtering is set on all trusts to prevent malicious users who have domain or enterprise administrator level access in a trusted forest from granting (to themselves or other user accounts in their forest) elevated user rights to a trusting forest. It does this by preventing misuse of the attributes containing SIDs on security principals (including inetOrgPerson) in the trusted forest. One common example of an attribute that contains a SID is the SID history attribute (sIDHistory) on a user account object. The SID history attribute is typically used by domain administrators to seamlessly migrate the user and group accounts that are held by a security principal from one domain to another.

When security principals are created in a domain, the domain SID is included in the SID of the principal to identify the domain in which it was created. The domain SID is important because the Windows security subsystem uses it to verify the identity of the security principal, which in turn determines what resources in the domain the principal can access.
How SID History is used to migrate accounts

Domain administrators can simplify account migration by using the SID history attribute to migrate permissions, either automatically by using the Active Directory Migration Tool (ADMT) or manually by adding SIDs from an old user or group account to the SID history attribute of the new, migrated account. With either method, the new account retains the same level of permissions or access to resources as the old account. If domain administrators could not use the SID history attribute in this way, they would have to determine and reapply permissions on each network resource to which the old account had access. For more information about the SID history attribute, see “Trust Security and Other Windows Technologies.”
How SID History can be used to elevate privileges

Although SID history has legitimate and important uses, it can also pose a security threat when used to exploit an unprotected trust. A malicious user with administrative credentials who is located in a trusted forest could monitor network authentication requests from the trusting forest to obtain the SID information of a user, such as a domain or enterprise administrator, who has full access to resources in the trusting forest. After obtaining the SID of an administrator from the trusting forest, a malicious user with administrative credentials can add that SID to the SID history attribute of a security principal in the trusted forest and attempt to gain full access to the trusting forest and the resources within it.

This method of gaining access by granting unauthorized user rights to a user is known as an elevation of privilege attack. In an elevation of privilege attack, an attacker might apply the SID of a domain administrator located in a trusting forest to the SID history attribute of the attacker’s own account located in a trusted forest, get a ticket that would automatically include the new SID, and then use the ticket to access resources in the trusting forest. When the attacker requests the use of a resource, the access control mechanism considers all SIDs in the authorization data to determine if the principal has the rights to complete the requested action.

In an external trust scenario, a malicious user who has domain administrator credentials in the trusted domain is a threat to the entire trusting forest. In a forest trust scenario, a malicious user who has domain or enterprise administrator credentials in the forest root domain of the trusted forest is a threat to the entire trusting forest. Although the concept of elevating privileges by modifying SIDs is relatively easy to understand, it is quite difficult to implement. Attackers can use various technologies together with SID history to accomplish an elevation of privilege attack.
Application Programming Interfaces (APIs)

Windows includes APIs that facilitate account migration. These APIs are not exposed and can only be accessed on a system that has been patched to allow access to them. In this case, the APIs could be misused to add SIDs for a user from one domain to the SID history of a user in another domain. This is unlikely because these APIs require domain administrative credentials for both domains, including the domain being attacked. In order to overcome that security measure, malicious users would need to get the password of an account with domain administrative credentials before adding the SID. Attackers with access to such an account could more easily use it to accomplish their ultimate goal, rather than having to carry out an elevation of privilege attack to achieve the goal.

Read the rest of the article on TechNet.

Active Directory Security Group Resources

Laura Robinson (Microsoft) has 2 posts which are excellent resources when working on your Active Directory delegation model. These posts focus on the concept of an “Admin-Free Active Directory” meaning that there are no accounts in the powerful AD groups: Enterprise Admins, Domain Admins, Administrators, & Schema Admins.

The posts also list all of the groups that, by default, have the rights to log onto Domain Controllers. These groups need to be tightly controlled and monitored.

These groups are listed here:

  • Enterprise Admins (member of the domain Administrators group in every domain in the forest)
  • Domain Admins (member of the domain Administrators group)
  • Administrators
  • Backup Operators
  • Account Operators
  • Print Operators

The last two groups on this list may surprise you. If so, you may want to audit membership in these groups since accounts in any of these groups have log on locally rights to the Domain Controllers in the domain.

Laura’s Blog Posts:
Part 1- Understanding Privileged Groups in AD
Part 2- Protected Accounts and Groups in Active Directory

Microsoft Key Management Server (KMS) Details

KMS Introduction

The Microsoft Key Management Server (KMS) is part of the Microsoft Volume Activation 2.0 solution managing Windows OS activation keys and performs activation for supported clients automatically. Starting with Windows Server 2008 & Windows Vista, Microsoft switched to an online activation system where every Windows OS requires activation.  KMS shifts the activation requirement to a single machine which is activated with a special KMS Host (server) key.  Every KMS supported Windows version automatically communicates with the KMS server to activate Windows and manage the activation key (configuring the Windows OS with a KMS key forces it to find a KMS Host and get activation from it).
KMS supported clients include Windows Server 2008, Windows Server 2008 R2, Windows Vista, & Windows 7.

The KMS client discovers the KMS server by performing a DNS query for the KMS SRV record in DNS.

DNS: Standard query SRV
DNS: standard query response SRV  0 100 1688 (addr

The DNS query response includes the KMS server hostname and port number (1688).
The KMS client then initializes a connection to port 1688 on the KMS server.

By default, a Windows installation’s license is configured with a grace period of 30 days plus 2 “rearms” (slmgr.vbs /rearm) for a total of  90 days to activate. Once activated by KMS, the KMS client communicates with the KMS server every 7 days to renew its activation as well as resetting the license counter to 0.

If the Windows license isn’t re-activated by a KMS server within 180 days (6 months), it shifts into a 30 day grace period after which it enters reduced functionality mode (retail only) or notification mode (where the user is notified regularly to re-activate) and continues to attempt a KMS connection every 2 hours until activated.


  • KMS doesn’t activate Windows workstations until at least 25 different Windows workstations have connected to KMS.
  • Also, KMS doesn’t activate Windows servers until at least 5 different Windows servers have connected to KMS.
  • Running slmgr.vbs /dli on the KMS Host provides the KMS activation count (a count of -1 means no clients have been activated).
  • Microsoft Office products are activated with a special KMS version & license key specific to Office.
  • Apparently the KMS Host in Windows 2008 prior to SP2 (and Windows 2008 R2) didn’t update the activated client count when activating virtual machines. Windows 2008 SP2 (and later) now updates the KMS count regardless of machine type, virtual or physical.

KMS Server Installation

Installing the KMS Host (Server) on a machine is simply a product key that gets activated on the computer which initializes the Software Protection Service to listen on port 1688 for license activation requests.  A multi-purpose enterprise server is the best candidate for KMS Host since the service is relatively lightweight. I don’t recommend configuring a Domain Controller as the KMS Server since a DC should only be providing Active Directory services (and DNS in most cases). This mitigates additional impact should a DC be taken down or reinstalled. The KMS Server can be installed on the same server as the DFS root name server and can also be virtualized (which may be ideal since High Availability can be easily enabled using VMWare HA).

A single KMS Server can handle the load of a large enterprise and it is not likely necessary to install a second (or more) KMS Server.  Many organizations choose to install 2 KMS Hosts to ensure license activations continue with the loss of a single server. However, going through the KMS Host activation process on an isolated network (not directly connected to the internet) is a time-consuming process. For this reason, it is recommended to use a server for KMS that can be easily restored from backup without affecting other services (this way the KMS Host key is restored on the same hardware).

Installing a KMS sever on the network is relatively straight forward.

  1. Identify a server on the network and install the appropriate KMS key by running slmgr.vbs /ipk <KmsKey> a Windows 2008 R2 server.
  2. Activate the KMS key on the KMS host by running slmgr.vbs /ato to activate online or run slui.exe 4 to activate by phone (for networks not connected to the internet).
  3. Restart the Software Protection Service by running restart-service sppsvc in an elevated PowerShell console (or net stop sppsvc && net start sppsvc if PowerShell is unavailable).
  4. Run slmgr.vbs /dli to get the KMS activated client count.

KMS Host installation performs a dynamic DNS update for a new SRV record (_VLMCS._TCP ) on port 1688. If the DNS server does not support dynamic DNS, the SRV record has to be manually created.

KMS SRV record:

Service: _VLMCS
Protocol: _tcp
Port: 1688
Priority: 10 (default is 0)
Weight:   0 (default is 0)
Host offering the service:
(enter FQDN with trailing “.”)

When configuring a second KMS server on the network, it is necessary to manually create the 2nd KMS SRV record in DNS. This is due to the original KMS sever owning the KMS SRV record that it dynamically created in DNS. Since the original KMS server owns the KMS SRV record, no other computer can update it. This is also why when replacing a KMS server, the new KMS server can’t update the existing KMS SRV DNS record.

KMS automatic DNS publishing can be disabled by running Slmgr.vbs /cdns.

The KMS Server only creates a KMS SRV record for its domain (Primary DNS Suffix). In order to configure the KMS Server to publish its KMS SRV DNS record to multiple domains:

To automatically publish KMS in multiple DNS domains, add each DNS domain suffix to whichever KMS should publish to the multi-string registry value DnsDomainPublishList in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform. After changing the value, restart the Software Licensing Service to create the SRV RRs.

KMS Host Key Types

The KMS Host key is directly related to the highest level OS used on the network, and there is a different KMS key series for Windows 2008 versus Windows 2008 R2.

A KMS key is used to activate only the KMS host with a Microsoft activation server. A KMS key can activate up to six KMS hosts with 10 activations per host. Each host can activate an unlimited number of computers. If you need to activate more than six KMS hosts, contact your Volume Licensing Service Center (, and state why you must increase the activation limit.

Windows Server 2008 R2 Standard edition is currently the highest product being deployed in the product grouping hierarchy (with Windows Server 2008 being below it and unable to activate Windows 2008 R2 servers). The associated KMS key for that product is the Windows Server 2008R2 _____ KMS _ key (where  _________ is the Server edition type and _ is “A”, “B”, or “C” ).

  • KMS C Key: Server Group C for Windows Server 2008 R2 (Editions: Datacenter & Itanium-based systems)
  • KMS B Key: Server Group B for Windows Server 2008 R2 (Editions: Standard & Enterprise)
  • KMS A Key: Server Group A for Windows Server 2008 R2 (Editions: Web Server & HPC Server)
  • Win 7 KMS Key: Client VL for Windows 7 (Editions: Professional & Enterprise)

The KMS license groups are configured so that a KMS key can activate all products in its group as well as all groups below it.

  • Server Group C can activate Groups C, B, A, and Client VL
  • Server Group B can activate Groups, B, A, and Client VL
  • Server Group A can activate Group A, and Client VL

KMS Client Configuration

On the client, run cscript slmgr.vbs –dlv to get the current Windows OS license status. By default, a KMS Client performs a DNS SRV query to locate a KMS server. If auto-discovery is disabled, run slmgr.vbs /ckms to re-enable. Activated clients need to communicate within 180 days (6 months) after which they enter a grace period.

Change a client’s activation key to a KMS client key by running slmgr.vbs /ipk <KmsSetupKey> and activate by running cscript slmgr.vbs /ato.

A DNS query for the SRV record identifies the KMS Server on a network:

nslookup -type=srv
(where is the domain name)

KMS Client Setup Keys

Windows 7
Windows 7 Professional FJ82H-XT6CR-J8D7P-XQJJ2-GPDD4
Windows 7 Professional N MRPKT-YTG23-K7D7T-X2JMM-QY7MG
Windows 7 Enterprise 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
Windows 7 Enterprise N YDRBP-3D83W-TY26F-D46B2-XCKRJ
Windows 7 Enterprise E C29WB-22CC8-VJ326-GHFJW-H9DH4
Windows Server 2008 R2
Windows Server 2008 R2 HPC Edition FKJQ8-TMCVP-FRMR7-4WR42-3JCD7
Windows Server 2008 R2 Datacenter 74YFP-3QFB3-KQT8W-PMXWJ-7M648
Windows Server 2008 R2 Enterprise 489J6-VHDMP-X63PK-3K798-CPX3Y
Windows Server 2008 R2 for Itanium-Based Systems GT63C-RJFQ3-4GMB6-BRFB9-CB83V
Windows Server 2008 R2 Standard YC6KT-GKW9T-YTKYR-T4X34-R7VHC
Windows Web Server 2008 R2 6TPJF-RBVHG-WBW2R-86QPH-6RTM4


Slmgr.vbs Parameters

Parameter Description
/sprt PortNumber Sets the TCP communications port on a KMS host. Replace PortNumber with the TCP port number to use. The default setting is 1688.
/cdns Disables automatic DNS publishing by a KMS host.
/sdns Enables automatic DNS publishing by the KMS host.
/cpri Lowers the priority of KMS host processes.
/spri Sets the priority of KMS host processes to Normal.
/sai ActivationInterval Changes how often a KMS client attempts to activate itself when it cannot find a KMS host. Replace ActivationInterval with a number of minutes. The default setting is 120.
/sri RenewalInterval Changes how often a KMS client attempts to renew its activation by contacting a KMS host. Replace RenewalInterval with a number of minutes. The default setting is 10080 (7 days). This setting overrides the local KMS client settings.
/dli Retrieves the current KMS activation count from the KMS host

Slmgr.vbs can be rum against a remote computer by using these additional parameters (omit username and password to use current credentials):

slmgr.vbs TargetComputerName [username] [password] /parameter [options]


KMS Part 2




Microsoft KMS Server

The KMS Server is the Key Management Server for Microsoft product activation, primarily OS activation. An organization can configure a KMS Server to service all activation requests in the enterprise.  In order for the KMS Server to activate Windows 7, the easiest method is to install KMS on a Windows 2008 R2 server (Windows 2003 & 2008 require an update to activate Windows 2008 R2 & Windows 7).  The KMS Server will communicate with Microsoft servers on the Internet to activate the KMS license.  If the KMS Server is installed on an isolated network, KMS can be activated with a phone call.

KMS requires a KMS key for volume activation which is typically the Windows Server 2008 Standard/Enterprise KMS B activation key.  This is the key that is entered as the server’s product key at the Windows Activation window which is all that is necessary for configuring a KMS server.  There is a caveat to this; there needs to be at least 5 servers communicating with the KMS host for server activation to occur or 25 Windows 7 or Vista machines for client activation.  This single KMS key is good for 6 KMS servers, if more are needed, a call to Microsoft is necessary for more. A single KMS host can handle the activation requirements for even a very large organization with tens of thousands of machines.

The KMS license keys have letter designations that describe the Windows product type that can be activated:

  • Group A includes Server 2008 R2 Web Edition and will activate other A group servers and Windows 7/Vista Volume Editions.
  • Group B includes Server 2008 R2 Standard/Enterprise Edition and will activate B group and A group servers plus Windows 7/Vista Volume Editions.
  • Group C includes Server 2008 Datacenter and will activate A/B/C group servers and Windows 7/Vista Volume Editions.

This information can also be found on Microsoft Technet.
Office 2010 can also be activated leveraging an Office 2010 KMS host which is a separate download from Microsoft.  The Office 2010 KMS can co-exist with the KMS host that activates Windows.

Here is the information from Microsoft regarding the Office 2010 KMS host:

An Office 2010 KMS host is required if you want to use KMS activation for your volume license editions of Office 2010 suites or applications, Microsoft Project 2010 or Microsoft Visio 2010. When Office 2010 volume edition client products are installed, they will automatically search for a KMS host on your organization’s DNS server for activation. All volume editions of Office 2010 client products are pre-installed with a KMS client key, so you will not need to install a product key.

This download contains an executable file that will extract and install KMS host license files. Run this file on either 32-bit or 64-bit supported Windows operating systems. These license files are required for the KMS host service to recognize Office 2010 KMS host keys. It will also prompt you to enter your Office 2010 KMS host key and activate that key. After this is done, you may need to use the slmgr.vbs script to further configure your KMS host.

The Volume Activation Management Tool (VAMT) can help manage the activations.

Finding the KMS Server on your network is fairly easy.  On a Windows 2008 R2 Server or Windows 7 client, run “slmgr.vbs /dlv” on the server and it should return the name of the KMS Server.  Additional options for the slmr.vbs command are located on Microsoft TechNet.  This includes KMS Client options.

You can also do a DNS query:
nslookup -type=srv” (replace with your actual domain name).  This give you the KMS FQDN and IP.

Note: KMS listens on port 1688, so that needs to be open to the KMS Server.



Using Group Policy Preferences for Password Management = Bad Idea

Using Group Policy Preferences for Password Management = Bad Idea OR “How to Get Your Network Owned in Several Simple Steps”

One of my customers recently needed to change the local administrator password on several hundred Windows 7 workstations and was trying to determine the best method: PowerShell script or Group Policy Preferences.

The easy answer is to use Group Policy Preferences since it has a built-in mechanism for changing/managing local computer passwords. The problem is that while the password in Group Policy Preferences is encrypted using AES 256, the private key for the encryption is posted on MSDN. This means that Group Policy Preferences is vulnerable to password exposure.

Since the private key for this data is well known, using Group Policy Preferences to manage local computer passwords means these passwords are vulnerable to discovery. Since the Group Policy Preference data is stored in an XML file in SYSVOL (such as drives.xml, groups.xml, printers.xml, etc), all authenticated users in the domain has read access (they have to in order to apply Group Policy). This means that any authenticated user can open the Group Policy Preference XML file with the encrypted password and decrypt it using the AES key posted on MSDN. This AES key is part of every Windows computer that is Group Policy Preferences capable (native support in Windows 7 and newer; Windows Vista with an install; and Windows XP SP 2 & Windows 2003 SP1 with a patch, KB943729) in order for the computers to decrypt the password and use it. If the Group Policy Preference requires a password to be entered, it is stored in an XML file in SYSVOL. Despite the fact that the password is AES 256-bit encrypted (and base 64 encoded with padding if necessary), it is not secure. Microsoft does not recommend storing passwords in Group Policy Preferences (blog post linked below) and Windows Server 2012 displays a message with a similar warning.

Windows Server 2012 Group Policy Preference password Warning:







More information on how Group Policy Preferences are attacked is in the post “Finding Passwords in SYSVOL & Exploiting Group Policy Preferences“.

Here’s a sample groups.xml file from SYSVOL representing a Group Policy using Group Policy Preferences to add a new user to computers in the linked OU.

<?xml version=”1.0″ encoding=”utf-8″?>
<Groups clsid=”{3125E937-EB16-4b4c-9934-544FC6D24D26}”>
<User clsid=”{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}” name=”LocalTestUser” image=”0″ changed=”2013-07-04 00:07:13″ uid=”{47F24835-4B58-4C48-A749-5747EAC84669}”>
<Properties action=”C” fullName=”” description=”” cpassword=”sFWOJZOU7bJICaqvmd+KAEN0o4RcpxxMLWnK7s7zgNR+JiJwoSa+DLU3kAIdXc1WW5NKrIjIe9MIdBuJHvqFgbcNS873bDK2nbQBqpydkjbsPXV0HRPpQ96phie6N9tn4NF3KYyswokkDnj8gvuyZBXqoG94ML8M1Iq7/jhe37eHJiZGyi5IBoPuCfKpurj2″ changeLogon=”0″ noChange=”0″ neverExpires=”0″ acctDisabled=”0″ userName=”LocalTestUser”/>

cpassword above represents the encrypted password and I was able to browse to and save this file from SYSVOL with a regular domain user account. All that is left to do is to perform a Base64 unencode, then decrypt using the MSDN AES key.

Here’s the 32-byte AES key used to encrypt ALL Group Policy Preferences passwords in any domain:

4e 99 06 e8  fc b6 6c c9  fa f4 93 10  62 0f fe e8
f4 96 e8 06  cc 05 79 90  20 9b 09 a4  33 b6 6c 1b

The problem is that since the AES encryption (and decryption) key is known (and posted publicly on MSDN and here), Group Policy Preferences can’t be considered a secure method for changing passwords.

The Microsoft Group Policy Blog posted about the potential issues in 2009:

Are passwords in preference items secure?
A password in a preference item is stored in SYSVOL in the GPO containing that preference item. To obscure the password from casual users, it is not stored as clear text in the XML source code of the preference item. However, the password is not secured. Because the password is stored in SYSVOL, all authenticated users have read access to it. Additionally, it can be read by the client in transit if the user has the necessary permissions.

Because passwords in preference items are not secured, we recommend that you carefully consider the security ramifications when deciding whether to store passwords in preference items. If you choose to use this feature, we recommend that you consider creating dedicated accounts for use with it and that you do not store administrative passwords in preference items.

Where can you use passwords?
You can use passwords in the following types of preference items:

  • Local User preference items: When you create or modify a local user account, you can specify both a user name and a password for the account.
  • Data Source preference items: If a user name and password are required to access the data source, you can provide them in the preference item. If you do so, end users to whom the preference item applies can access the data source regardless of their own permissions, but only if the specified account has the necessary permissions.
  • Mapped Drive preference items: You can specify the user name and password to be used to connect to a mapped drive. If you do so, end users to whom the preference item applies can access the mapped drive regardless of their own permissions, but only if the specified account has the necessary permissions.
  • Scheduled Task or Immediate Task preference items: You can configure a scheduled task to run under the security context of a specified user (allowing the task to run regardless of whether that user is logged on), by selecting the “Run as” check box and providing a user name and password.
  • Service preference items: You can modify which account the service runs under by selecting “Local System account” or by selecting “This account” and specifying a user name and password.

If this HAS to be done and you accept the risk, you can set the group policy for a few days and then delete it. However, there is a chance that someone already copied the XML file containing the password and already knows it. Using SCCM or a scripted solution may be the best answer for now, unless you want to pay for a product from CyberArk or Quest (note that these products are mentioned for informational purposes only).

Here’s a PowerShell script I wrote that reports on what credentials are stored in Group Policies. PowerShell Script: Discover Group Policy Passwords (updated 10/2014). Note that it requires the Active Directory PowerShell cmdlets.

Attack Vectors:

There is code on MSDN for managing local admin passwords for computers by storing the password in a confidential Active Directory attribute on each computer object. Note that this solution is not supported by Microsoft.


This sample is a fully working solution that implements automatic management of password of builtin Administrator account on computers joined to domain.

Solution currently available out of box on the platform (Group Policy Preferences) does not fulfill usual security requirements. Main problems with GPO Preferences are:

  • Password is the same on many workstations
  • Password stored in GPO and transported over network is not encrypted, but obfuscated (and obfuscation algorithm is published on MSDN), so it is not secure solution

Solution implemented by this sample does not have such weak points.