Apr 28 2014

AD Reading: Active Directory Backup and Disaster Recovery

The following are extremely useful resources for understanding the Active Directory Backup and Disaster Recovery.

Backup and Disaster Recovery

o   What’s New in AD DS Backup and Recovery?

o   Known Issues for AD DS Backup and Recovery

o   Best Practices for AD DS Backup and Recovery

o   General Requirements for Backing Up and Recovering AD DS

o   Scenario Overviews for Backing Up and Recovering AD DS

o   Steps for Backing Up and Recovering AD DS

o   New Features, Assumptions, and Prerequisites for Using This Guide for Planning Active Directory Forest Recovery

o   Devising a Custom Forest Recovery Plan

o   Recovering Your Active Directory Forest

o   Appendix A: Forest Recovery Procedures

o   Appendix B: Frequently Asked Questions

o   Appendix C: Recovering a Single Domain within a Multidomain Forest

o   Appendix D: Forest Recovery with Windows Server 2003 Domain Controllers

o   Additional Resources

o   Restore Active Directory from backup

o   Mark the object or objects authoritative

o   Synchronize replication with all partners

o   Run an LDIF file to recover back-links

o   Restart the domain controller in Directory Services Restore Mode locally

o   Create an LDIF file for recovering back-links for authoritatively restored objects

o   Turn off inbound replication

o   Turn on inbound replication

Apr 27 2014

AD Reading: Active Directory Authentication & Logon

The following are extremely useful resources for understanding the Active Directory Authentication & Logon.

Authentication & Logon

o   Digest Authentication Technical Reference

o   Interactive Logon Technical Reference

o   Kerberos Authentication Technical Reference

o   TLS/SSL Technical Reference

o   Introduction

o   Overview of the Kerberos Protocol

o   Kerberos Components in Windows 2000

o   Authorization Data

o   Interactive Logon

o   Remote Logon

o   Interoperability

o   Introduction (Kerberos Protocol Transition and Constrained Delegation)

o   Authenticating Web Application Users

o   Windows Server 2003 Kerberos Extensions

o   Sample Scenario Source Files

o   Summary (Kerberos Protocol Transition and Constrained Delegation)

o   Conclusion (Kerberos Protocol Transition and Constrained Delegation)

o   Security Descriptors and Access Control Lists Technical Reference

o   Access Tokens Technical Reference

o   Permissions Technical Reference

o   Security Principals Technical Reference

o   Security Identifiers Technical Reference

o   What is Interactive Logon?

o   How Interactive Logon Works

o   Interactive Logon Tools and Settings

o   User Profiles Overview in User Data and Settings Management

o   User Profile Structure

o   Enhancements to User Profiles in Windows Server 2003 and Windows XP

o   How to Configure a Roaming User Profile

o   Security Considerations when Configuring Roaming User Profiles

o   Best Practices for User Profiles

o   Folder Redirection Overview

o   How to Configure Folder Redirection

o   Security Considerations when Configuring Folder Redirection

o   Best Practices for Folder Redirection in User Data and Settings Management

o   Related Technologies: Offline Files and Synchronization Manager

o   Common Scenarios for IntelliMirror User Data and Settings Features

o   Appendix: Group Policy Settings for Roaming User Profiles

o   Related Links for User Data and Settings Management

Apr 27 2014

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

Apr 27 2014

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

 

 

 

Apr 27 2014

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:

Mar 19 2014

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.

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:

 

 

Load more