Feb 28 2014

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

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

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
Host: <KMS-HOST-FQDN>

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

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

References:

Feb 23 2014

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.

Feb 15 2014

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.

Default-DC-LogOnLocallyGroups
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

Feb 13 2014

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  _vlmcs._tcp.adsecurity.org
DNS: standard query response SRV  0 100 1688 kms.adsecurity.org (addr 10.10.10.11)

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.

NOTE:

  • 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: kms.adsecurity.org.
(enter FQDN with trailing “.”)

NOTE:
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 (http://go.microsoft.com/fwlink/p/?LinkId=184280), 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  _vlmcs._tcp.adsecurity.org
(where adsecurity.org 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


References:

 

 

Feb 01 2014

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 _vlmcs._tcp.adsecurity.org” (replace adsecurity.org 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.

Cheers,
Sean

References:

Jul 03 2013

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:

Windows2012-GPP-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”/>
</User>
</Groups>

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.

Summary

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.

Nov 17 2012

Windows 2012 RID Management

While “1 Billon RIDs should be enough for anyone,” there are scenarios where a domain could run out of RIDs. This is a “very bad thing” since every security principal requires a RID for creation (Domain SID + RID = security principal SID).  One can check the number of RIDs remaining in a domain through many different tools (PowerShell).

DCDIAG:

Dcdiag.exe /TEST:RidManager /v | find /i “Available RID Pool for the Domain”

 

########################
# Get Domain RID Info #
#######################
## Based on code From https://blogs.technet.com/b/askds/archive/2011/09/12/managing-rid-pool-depletion.aspx
Import-Module ActiveDirectory
Write-Verbose “Get RID Information from AD including the number of RIDs issued and remaining `r “
$RIDManagerProperty = Get-ADObject “cn=rid manager$,cn=system,$ADDomainDistinguishedName” -property RIDAvailablePool -server ((Get-ADDomain $DomainDNS).RidMaster)
$RIDInfo = $RIDManagerProperty.RIDAvailablePool
[int32]$TotalSIDS = $RIDInfo / ([math]::Pow(2,32))
[int64]$Temp64val = $TotalSIDS * ([math]::Pow(2,32))
[int32]$CurrentRIDPoolCount = $RIDInfo – $Temp64val
$RIDsRemaining = $TotalSIDS – $CurrentRIDPoolCount

$RIDsIssuedPcntOfTotal = ( $CurrentRIDPoolCount / $TotalSIDS )
$RIDsIssuedPercentofTotal = “{0:P2}” -f $RIDsIssuedPcntOfTotal
$RIDsRemainingPcntOfTotal = ( $RIDsRemaining / $TotalSIDS )
$RIDsRemainingPercentofTotal = “{0:P2}” -f $RIDsRemainingPcntOfTotal

Write-Output “RIDs Issued: $CurrentRIDPoolCount ($RIDsIssuedPercentofTotal of total) `r “
Write-Output “RIDs Remaining: $RIDsRemaining ($RIDsRemainingPercentofTotal of total) `r “

Windows Server 2012 provides the capability to expand the RID pool to 2 billion RIDs by reclaiming the 31st bit (through SidCompatibilityVersion). Of course, this is a last resort scenario since a domain of all 2012 DCs is highly recommended (though 2003 and newer have a hotfix for supporting this “feature”).

Windows 2012 provides several RID protection mechanisms:

  • Artificial RID ceiling of 10% of maximum (107,374,183 RIDs remaining) preventing new RIDs from being delivered from the RID Master.
  • Constant warnings at 1% of maximum – Events are logged whenever a DC request RIDs and on the RID Master when providing RID blocks.
  • Block size cap – sets a maximum valid value for DC RID pool request size (default: 500 RIDs). Note that 2012 introduces a max RID pool request of 15,000.

All of the details at the ASKDS Blog:
ASKDS covers Windows Server 2012 RID Expansion

 

Mar 06 2012

My Journey to Become a Microsoft Certified Master (MCM) Part 2: The MCM Program

NOTE: I do not work for Microsoft, nor have I ever worked for Microsoft. The information in this post is my thoughts and not those of Microsoft or any other company. Unless said company read my mind and placed some thoughts there… I should buy a Dell… 🙂

The content in this post belongs to Sean Metcalf and may not be used for any purpose without express written consent by him.

Also, NOTHING in these posts will get you to pass and become a Microsoft Certified Master (MCM).  Only your knowledge & experience and internal motivation to be the best will do that. Sure, you can gleam some ideas that will help you prepare, but the MCM Program doesn’t teach to the test. You are tested on potentially anything and EVERYTHING that is Active Directory related (check the pre-reading list for topic coverage). The tests are extremely difficult. You are expected to be at the top of your game to pass.

I use both “Active Directory” and “Directory Services” interchangeably. The official certification is Microsoft Certified Master Directory Services (Windows Server 2008 R2).

This is Part 2, continued from Part 1, My Journey to Become a Microsoft Certified Master (MCM) Part 1: The Journey Begins

Arrived!

I arrived safely and checked into the motel of a hotel which is small, but serviceable. At least it is about 1 block away from the building I need to walk to every day (and 7-Eleven is 1 block the other way). I found that Safeway, an office supply store, a Thai restaurant, Red Robin restaurant, Arby’s, 5 Guys, Subway, and many other stores were about a 15 minute walk from the hotel.

The taxi from the airport was a Prius and cost about $60 to the Homewood Suites Hotel in Bellevue, WA. This sign in the taxi caught my attention.

NOTE: If you need a decent, cheap hotel to stay in during the MCM Program, the Homestead is OK.  If I had to do it again, I would seriously consider the Residence Inn which is only a few minutes more walk to the Microsoft building we were in. Homestead now has free WiFi & wired Internet, but still only provides servicing the room once a week. There’s a small, small kitchen area with a sink, microwave, stove top, and regular Refrigerator. It was suitable for my needs while there.

Sunday night I spent eating delivered pizza watching Super Bowl XLVI (46). I relaxed and didn’t read anymore figuring my brain needed a night off before the pain started. Enjoyed the game and found myself wondering if Madonna was 50 or 60 (she’s 54)…

The hotel room:


Day One: Monday (2/6/2012)
One month ago today, I started the first day at 7am to get badged, signed NDA documents, and at about 7:30am arrived in the classroom – my home for the next 2 weeks.

The Microsoft Building

There were 24 people attending this “14th Rotation” of the Directory Services Master program, 5 people from overseas (not Microsoft), 3 people from the US (not Microsoft), and 15 Microsoft PFEs from around the world (Asia, Australia, Canada, Russia, Romania, etc) . Everyone seems to have about 7-10 years AD experience (one person joked they had 15 years of AD experience since they worked with Exchange).  The PFEs are, as expected, knowledgeable and… chatty. In a good way. They are relaxed and ready for the next 14 days.  60% of the people in the room is Microsoft employed &  trained personnel from all over the world and are considered at the top of their game – this leads to some interesting customer stories (single DC for a single domain forest became corrupt… what to do…).

At around 8am MCM DS PM Ryan Conrad told us what to expect: this is the largest MCM DS class yet and based on statistics, only about 8 people will attain MCM status this rotation. Yup, 8 out of 23. Sobering words. 11 ended up passing this MCM rotation, but I’m jumping ahead. We learn that class this week is Monday – Saturday (though only 4 hours on Saturday) and we have Sunday off.  I don’t quite view Sunday as a day off considering our first test is on Monday which makes Sunday a study day for me.

Some other items Ryan pointed out (and my observations):

Continue reading

Feb 28 2012

My Journey to Become a Microsoft Certified Master (MCM) Part 1: The Journey Begins

Just a quick note before I start. I do not work for Microsoft and have never worked for Microsoft. The information in this post is my thoughts and not those of Microsoft, or any other company. Unless said company read my mind and placed some thoughts there… I should buy a Dell… 🙂

The content in this post belongs to Sean Metcalf and may not be used for any purpose without express written consent by him.

Also, NOTHING in these posts will get you to pass and become a Microsoft Certified Master (MCM).  Only your knowledge & experience and internal motivation to be the best will do that. Sure, you can glean some ideas that will help you prepare, but the MCM Program doesn’t teach to the test. You are tested on potentially anything and EVERYTHING that is Active Directory related (check the pre-reading list for topic coverage). The tests are extremely difficult. You are expected to be at the top of your game to pass.

Also, I use both “Active Directory” and “Directory Services” interchangeably. The official certification is Microsoft Certified Master Directory Services (Windows Server 2008 R2).
This post is part 1 of 2. Looking for part 2?  My Journey to Become a Microsoft Certified Master (MCM) Part 2: The MCM Program

The Journey Begins:

Years ago I heard about the Microsoft Ranger program which started with an internal Microsoft group of Exchange experts (Yes, I think I will name drop here: I worked closely with Ross Smith for a while many years ago). This program grew into what is now the Microsoft Certified Master (MCM) & Microsoft Certified Architect (MCA) programs. I did consider the MCM a few years ago when it was 3 weeks long, but I couldn’t get over a few psychological barriers:  Have I worked on large enough environments? Did I know enough? Am I good enough? Three weeks is a really long time…

In early 2011, my close friend, De  challenged me with an email stating simply:

I see your future… And the future looks bright…  So what’s stopping you?
Yeah.. so anyway. What can I do to help you begin preparing for the MCM? Or what can I do to help ENCOURAGE you to prepare for your MCITP Enterprise Administrator? whichever…

In the email was a link to the MCM Program. I looked it over and remember saying to myself (because occasionally I say stuff to me & vice versa), “yes in good time”.  At that point, I still hadn’t become an MCITP, which meant I was a tad behind.
<SmallAmountOfBoasting> I mean when I picked up MCSE in 1997, I took and passed all of the required 6 tests in 6 weeks. I was a bit lazier on the Windows 2000 MCSE and spent a few months on that taking all the necessary tests to pick up the new MCSE title without the upgrade tests. The Windows 2003 MCSE seemed to take up the better part of a year due to my certification lack of focus and stubborn resistance to taking upgrade exams. Maybe that’s part of the challenge for me – doing the whole thing from scratch, forcing myself to understand the nuances from OS to OS… I digress. </SmallAmountOfBoasting>

So, in March of 2011, I committed to myself & my good friend De that I would pass all the necessary tests to become a MCITP:EA by the end of May. Oh, one other thing I forgot to mention, I had 1 year old triplets in the house at that time, so doing anything like going off in a corner to read & study was a challenge. Apparently, that’s what I needed. A good challenge. I passed the requisite 5 tests in 4 weeks (I took 2 on the first Saturday) and had achieved my goal of MCITP ahead of time as well as busting my previous personal Microsoft test-taking record.

About a month after the MCM email from my buddy D, I replied back with the link to the MCM program.

So, I think it is about time for me to step up to the big league.

At that point, I embarked on a journey towards an industry advanced certification (Microsoft Certified Master, aka MCM) that about 600 people in the world have attained. I took this journey seriously and approached it like it was a black belt in martial arts. Or becoming a Jedi Master. I’ll go with the latter.

With the MCITP:EA behind me, I looked forward to TechEd in May 2011 joined by my faithful sidekick— er, I mean best buddy, ol’ pal De While perusing the schedule of wall to wall sessions I couldn’t possibly attend unless I somehow figured out how to clone myself (and that didn’t work out so well for Micheal Keaton), although I do like pizza and the number 7…
Where was I…. Oh yeah. I discovered a small side-session off in the corner set up as a group discussion about the MCM program. They had me at MCM…

TECHED 2011
I ventured into the small session room along with about 20-30 other people interested in getting more information about the, at that time, effectively secret society known as the Microsoft Certified Masters.

This session was hosted by none other than David Burjam-Burr, Program Manager of the Exchange Masters program, I sat up front notebook ready. I learned some fascinating tidbits which also sounded a little frightening.

Here they are (all Exchange MCM related):

  • MCM became official in 10/2008 (which is when it was placed under Microsoft Learning)
  • ~4 rotations per year with about 20-30 people per rotation.
  • 3 weeks, Monday – Friday
  • Daily Agenda: 8am – 6pm + studying + homework
  • 3rd week: Friday & Saturday is final testing.
  • Qualification Lab = 6-8 hours long + lunch
  • Know the RFCs (SMTP, IMAP, POP, etc)
  • Exchange practice lab environment: On Premise + Cloud, 6 sites (networks), Multiple Orgs, multiple TMG firewalls

Screening Process:

  • Experience
  • Years at Senior Level
  • 750,000 seat deployment (Sean’s note: WOW.)
  • Register about 6 months prior to desired rotation

At least that’s what I found when reading through my chicken-scratch. It may be different by now, or not.

Needless to say, not much regarding the AD (Directory Services) stuff which I as most interested in. I think there was 1 maybe 2 other people in the room interested in the AD MCM. Oh, here’s another note to make on feel more confident about the MCM path, (yes, sarcasm): there was one MCM in the room and he didn’t pass until the 3rd test (2 retakes)! Talk about a confidence booster!

After the session I scoured the Microsoft Q&A areas attempting to seek out an MCM to ask all the MCM DS questions I had preventing me from thinking about anything else. I found one & De and I cornered him, though we were shortly humbled by his MCM-level knowledge.

Reminds me a little of a story about a couple of DJs that used to broadcast in the DC Area (Don & Mike) and a former Super Bowl winning Quarterback & Hall of Famer named Joe Theisman. They were out playing golf one day and Don & Mike were giving Joe a hard time about his golf game (as I understood it, Joe was/is the consummate competitor and was having an off day). Joe spun around at the 12th hole and got in their faces and said “Tell you what, when you have one of these you can talk sh$# until then shut the F#$$ up and play some golf”. This was said quite forcefully as he held up the oversized, diamond encrusted Super Bowl XVII ring in their faces. As I understand it, the rest of the game was rather quiet until D&M bought all the rounds at the 19th hole. Or nothing like that may have ever happened… but it makes a good story. In other words, when you have reached a level in your career, you have no need to say anything. The “Master” was gracious enough to entertain our questions and I learned the following tidbit:

Each test question takes about 2-3 hours to develop and are tested by special “test psychologists” (Psychomatricians https://en.wikipedia.org/wiki/Psychometrics). These test specialists ensure that someone who is expert at taking tests can’t pass without knowing the answer. Tough tests indeed.

I walked out of the Atlanta Convention Center that day with a new challenge.  A new purpose. I told my lovely wife that I was going to go to the MCM Directory Services program less than a year later, April 2012 (it was later moved to February). The gracious person that she is, simply said “sure, we’ll talk about it later.” Later involved me reasoning why I could go in October, mere months away. My determination kept my excitement level up as well as my ambition to become a Master.

Application Time!

I spent May & June preparing an application package for the program (many apply, not all are accepted).

The pre-requisites for the application are:

Continue reading