Jun 05 2014

Great InfoWorld Interview with Mark Russinovich on Azure and Cloud Computing

InfoWorld has a great Interview with Mark Russinovich, Microsoft Technical Fellow, on Azure and Cloud Computing.
I included my favorite quotes below:

Intro:

Mark Russinovich is a legendary figure in the computer industry. A former teenage hacker who went on to earn a PhD in computer engineering from Carnegie Mellon, Russinovich cofounded Winternals Software — a Windows utilities vendor renowned for understanding the guts of Windows as well as Microsoft itself.

After a stint at IBM’s Thomas J. Watson Research Center and after discovering a number of high-profile Windows security vulnerabilities, not to mention the infamous Sony rootkit[1], Russinovich joined Microsoft when Winternals was acquired in 2006. Russinovich is also an accomplished novelist, whose cyberthrillers Zero Day and Trojan Horse have been well received (the third novel in the series, Rogue Code, comes out this May).

Today, Russinovich is a Technical Fellow, the highest technical position at Microsoft. He’s the sole Technical Fellow in the Windows Azure Group, acting as lead architect for Microsoft’s bet-the-company cloud initiative — $15 billion have been invested in cloud infrastructure to date. Much of what Russinovich has been working on pertains to the complex automation necessary to manage that cloud infrastructure at scale. The interview began with an examination of Azure technology and moved to broader concerns about IT’s march to the public cloud. The folllowing is an edited version.


On Microsoft Cloud Transparency:

I think that’s one place where we’ve been way more transparent than anybody else. I’ve given talks for three years since I joined Azure at TechEd and Build on Windows Azure Internals about how our virtual machine technology is implemented and how we implement that multitenancy. You don’t see Amazon or Google talking about that.


Azure Overview:

Sure. When it comes to virtual machines, which are really the building blocks of the cloud, we’ve got pools of servers, we’ve got something called a fabric controller, which is like the brain.

The Azure fabric. And that manages a pool of machines. And then there’s an application front-end, a virtual machine deployment front-end we call RDFE — Red Dog Front End. Red Dog is a carryover from Microsoft from Azure’s code name.

Here’s what happens when a customer deploys a PaaS application (what we call a Cloud Service, a collection of virtual machines) or when they deploy IaaS as virtual machines: It goes to RDFE, then RDFE finds a fabric controller that has, based on heuristics, the best utilization and capacity available for the deployment and gives the deployment to the fabric controller, which then goes and finds servers to deploy the virtual machines onto.

It uses a bunch of heuristics as well as constraint satisfaction to figure out which servers are the ones that the virtual machines should land on. We’ve got the concept of update domains and fault domains [5], so that when the infrastructure is being updated we don’t take down the whole application. We split the application across different servers so that when we’re servicing the infrastructure of the servers, it’s only taking down a slice of the application.


Regarding the future of computing:

When I joined Microsoft, I’d done a lot of Windows stuff before, but operating systems had already pretty much matured. I mean, Windows today in the internals isn’t very different than 20 years ago, and Linux is the same way — just like UNIX back in the ’70s.

This cloud operating system, data center operating system, is brand new. So the problems are new, the algorithms are new, the computer science is new. How do you detect failures quickly? How do you respond to them? How do you best do resource allocation?


Active Directory as the central piece of Azure:

One of the most valuable assets that we recognize within Microsoft when it comes to cloud and getting that integration is Windows Azure Active Directory.

The name is not a mistake. It’s completely deliberate because Active Directory became the center of on-premises network architecture. And we see Windows Azure Active Directory becoming that for the cloud.


Cloud Technology is in it’s infancy:

We’re constantly adding new functionality and features. Like I said, the cloud is new. If you look at the mature environment of the on-premises IT world, there’s not just one thing that does whatever you want it to, but probably 20 or 30 different vendors that offer products that do what you’re talking about. The cloud is not there yet. There are a lot of holes in the basic functionality, in the layered functionality of the services that would be added on top of that. This is why it’s going to be just a great economic opportunity for lots of people.


IT Career Advice:

If you look at the evolution of IT, people aren’t doing today what they were doing ten years ago. Change has just been a fact of life all along.

Now, of course, some changes are bigger than others. But change has been there all along. And if you’re not adapting, you shouldn’t be in this business. IT professionals, I think, have to step up and play a key role in this migration for their companies. Because if they don’t, shadow IT is just going to go around them

 

Read the rest of the interview at InfoWorld.

 

Jun 03 2014

PowerShell is Central to Everything Microsoft

So how important is Windows PowerShell? Well for starters, Windows PowerShell grabbed three of the top ten TechEd 2014 talks in Houston this year. PowerShell.Org printed out 3,000 DSC Resource guide books to hand out at the Scripting Guys booth, and to give out in presentations – they were gone in two days. In addition, there have been more than 10,000 downloads of the electronic version from the web site. At the Scripting Guys booth this year, we talked to more than 5,000 people during the week. This equates to like ½ of all attendees at TechEd – and after the first two days, we had nothing to give away – but people came to talk to Windows PowerShell people. This is incredible.

http://blogs.msdn.com/b/powershell/archive/2014/06/02/powershell-predict-the-future-via-teched.aspx

Jun 02 2014

Active Directory 2012 DCPromo

Starting with Windows Server 2012, DCPromo is no longer used to promote a member server to be a Domain Controller. Since DCPromo no longer works (Microsoft calls this featured deprecated), there is a new GUI option and associated Powershell commandlets.

There are major changes to the promotion process which integrate the process. This simplified process includes:

  • AD DS role deployment is now part of the new Server Manager architecture and allows remote installation.
  • The AD DS deployment and configuration engine is now Windows PowerShell, even when using a graphical setup.
  • Promotion now includes prerequisite checking that validates forest and domain readiness for the new domain controller, lowering the chance of failed promotions.
  • The Windows Server 2012 forest functional level does not implement new features and domain functional level is required only for a subset of new Kerberos features, relieving administrators of the frequent need for a homogenous domain controller environment.

NOTE: The new “DCPromo” GUI takes longer than before since it performs many more checks than in the past. Since the GUI provides the PowerShell script code, it’s a great idea to script the promotion of all new 2012 DCs.

Install the Active Directory Domain Services (ADDS) role:

  1. Install the role “Active Directory Domain Services (ADDS)” on the target server (local or remote).
  2. Check the Restart checkbox.
  3. Click on Export Configuration Settings to get the Powershell command line equivalent.

Powershell command:

Add-WindowsFeature AD-Domain-Services

Promote the server to DC:

  1. Run the Active Directory Domain Services Configuration Wizard.
  2. Select Add a Domain Controller to an Existing Domain.
  3. Select the appropriate DC options and enter the DSRM password.
  4. Change any options on the following pages as appropriate.
  5. Click on View Script to view the Powershell script command.
  6. Click Install.

Here’s the Powershell script the GUI creates when creating a new forest accepting all defaults:

Import-Module ADDSDeployment
Install-ADDSForest `
-CreateDNSDelegation:$False `
-DatabasePath “c:\Windows\NTDS” `
-DomainMode “Win2012″ `
-DomainName “MCLab.net” `
-DomainNetbiosName “MCLAB” `
-ForestMode “Win2012″ `
-InstallDNS:$true `
-LogPath “C:\Windows\NTDS” `
-NoRebootOnCompletion:$false `
-Sysvolpath “C:\Windows\SYSVOL” `
-Force:$true

Here’s the Powershell script the GUI creates when adding a new Domain Controller to an existing domain accepting all defaults:

Import-Module ADDSDeployment
$SafeModeAdministratorPasswordText = ‘&P@ssw0rd2013&’
$SafeModeAdministratorPassword = ConvertTo-SecureString -AsPlainText $SafeModeAdministratorPasswordText -Force

Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-CreateDNSDelegation:$false `
-Credential (Get-Credential) `
-CriticalReplication:$false `
-DatabasePath “C:\Windows\NTDS” `
-DomainName “mcdevlab.net” `
-InstallDNS:$true `
-LogPath “C:\Windows\NTDS\Logs” `
-SiteName “Default-First-Site-Name” `
-SYSVOLPath “C:\Windows\SYSVOL” `
-Force:$true `
-SafeModeAdministratorPassword $SafeModeAdministratorPassword

Powershell AD commands (with switches):

Install-ADDSDomainController

-ADPrepCredential
-AllowDomainControllerReinstall
-AllowPasswordReplicationAccountName
-ApplicationPartitionsToReplicate
-CreateDnsDelegation
-Credential
-CriticalReplicationOnly
-DatabasePath
-DelegatedAdministratorAccountName
-DenyPasswordReplicationAccountName
-DnsDelegationCredential
-DomainName **
-Force
-InstallationMediaPath
-InstallDns
-LogPath
-MoveInfrastructureOperationMasterRoleIfNecessary
-NoDnsOnNetwork
-NoGlobalCatalog
-NoRebootOnCompletion
-ReadOnlyReplica
-ReplicationSourceDC
-SafeModeAdministratorPassword
-SiteName
-SkipAutoConfigureDns
-SkipPreChecks
-SystemKey
-SysvolPath
-UseExistingAccount
-Confirm
-WhatIf

Install-ADDSForest

-Confirm
-CreateDNSDelegation
-DatabasePath
-DomainMode
-DomainName **
-DomainNetBIOSName **
-DNSDelegationCredential
-ForestMode
-Force
-InstallDNS
-LogPath
-NoDnsOnNetwork
-NoRebootOnCompletion
-SafeModeAdministratorPassword
-SkipAutoConfigureDNS
-SkipPreChecks
-SYSVOLPath
-Whatif

Install-ADDSDomain

-ADPrepCredential
-AllowDomainReinstall
-CreateDnsDelegation
-Credential
-DatabasePath
-DnsDelegationCredential
-DomainMode
-DomainType
-Force
-InstallDns
-LogPath
-NewDomainName **
-NewDomainNetbiosName
-NoDnsOnNetwork
-NoGlobalCatalog
-NoRebootOnCompletion
-ParentDomainName **
-ReplicationSourceDC
-SafeModeAdministratorPassword
-SiteName
-SkipAutoConfigureDns
-SkipPreChecks
-SysvolPath
-Confirm
-WhatIf

** Required Powershell switches

DC Prerequisite Checking:
Domain controller configuration also implements a prerequisite checking phase that evaluates the forest and domain prior to continuing with domain controller promotion. This includes FSMO role availability, user privileges, extended schema compatibility and other requirements. This new design alleviates issues where domain controller promotion starts and then halts midway with a fatal configuration error. This lessens the chance of orphaned domain controller metadata in the forest or a server that incorrectly believes it is a domain controller.

The following tools are installed as part of the DC promotion:

  • Active Directory Administrative Center
  • Active Directory Domains and Trusts
  • Active Directory Module for Windows PowerShell
  • Active Directory Sites and Services
  • Active Directory Users and Computers
  • ADSI Edit
  • DNS
  • Group Policy Management

NOTE: Running dcpromo /unattend still installs the binaries as before, but produces a warning.
References:

May 29 2014

PowerShell: Useful WMI Classes

Here are some WMI Classes I have found useful:
  • Get-WmiObject -Class Win32_BIOS
  • Get-WmiObject -Class Win32_ComputerSystem
  • Get-WmiObject -Class Win32_OperatingSystem
  • Get-WmiObject -Class Win32_NetworkAdapter
  • Get-WmiObject -Class Win32_NetworkAdapterConfiguration
  • Get-WmiObject -Class Win32_Product
Enumerating Win32 WMI Classes:
[array]$WMINames = Get-WmiObject -Query ‘Select * From Meta_Class WHERE __Class LIKE “win32%”‘ |
Where-Object { $_.PSBase.Methods } |
Select-Object Name, Methods
$WMINames = $WMINames | sort -Property Name
$WMINames

May 27 2014

PowerShell Code: Get & Set Active Directory Tombstone Lifetime and Active Directory Delete & Recycle Operations

Active Directory is a multi-master database replicated among multiple Domain Controllers. In order to ensure that objects are fully replicated before deletions are processed (purged), objects that are marked for deletion before they are completely purged from Active Directory. Active Directory marks the object as deleted by performing the following actions on the object:

  • The isDeleted attribute of the deleted object is set to TRUE (objects with an isDeleted attribute value set to TRUE are called tombstones.)
  • The deleted object is moved to the Deleted Objects container for its naming context. If the object systemFlags property contains the 0x02000000 flag, the object is not moved to the Deleted Objects container. The Deleted Objects container is flat, so all objects reside at the same level within the Deleted Objects container.
  • Thus, the relative distinguished name of the deleted object is changed to ensure that the name is unique within the Deleted Objects container. If the original name is longer than 75 characters, it is truncated to 75 characters.
  • The following are then appended to the new name:
    A 0x0A character
    The string “DEL:”
    The string form of a unique GUID, such as “947e3228-70c9-4311-8b7a-e5c9b5bd4432”

 

The AD tombstone lifetime determines how long deleted items exist in AD before they are purged. The default value was originally 60 days, but this was increased to 180 days starting with new AD forests created with Windows 2003 SP1. While the tombstone lifetime directly affects deleted items, it also has an impact on Domain Controllers. If a DC hasn’t replicated within the tombstone lifetime with another DC, it is effectively orphaned from the domain. Additionally, DC backups are only useful for restoring AD data within this tombstone lifetime – a backup that is 181 days old is no longer useful when the tombstone lifetime is 180 days.

 

First Domain Controller Operating System Version Default Tombstone Lifetime Setting (days)
Windows 2000 Server 60
Windows Server 2003 RTM 60
Windows Server 2003 R2 (SP1) 60
Windows Server 2003 SP1 and SP2 180
Windows Server 2003 R2 SP2 180
Windows Server 2008 and higher 180

Since this value is stored as an attribute (tombstonelifetime) on the AD object “cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=<forestDN>”, it can be queried and modified.

There are some changes to how this process works once the AD Forest is set to Windows Server 2008 R2 mode and the AD Recycle Bin is enabled.Once enabled, there is a 180 day threshold from when an object is deleted by an admin within which it may be restored. Then at day 181, it is effectively “tombstoned” and may not be restored using the recycle bin undelete method. At day 360, this object is removed from the directory (purged). In other words, enabling the recycle bin keeps the object in the directory for 360 days after it is deleted. Microsoft states that this increases the size of AD by about 10 – 15%.

The AD Recycle Bin enables rapid restoration of deleted objects without a restore operation by implementing two new attributes, and using two existing attributes:

  • isDeleted

    • Has existed since Windows 2000
    • Exists on every object
    • Describes if an object is deleted but restorable
  • isRecycled

    • New to Windows Server 2008 R2
    • Exists on every object once it is recycled
    • Describes if an object is deleted but not restorable
  • msDS-deletedObjectLifetime

    • New to Windows Server 2008 R2
    • Is set on the “CN=Directory Service,CN=Windows NT, CN=Services, CN=Configuration, DC=COMPANY,DC=COM” container
    • Describes how long a deleted object will be restorable
  • tombstoneLifetime

    • Has existed since Windows 2000
    • Is set on the “CN=Directory Service,CN=Windows NT, CN=Services, CN=Configuration, DC=COMPANY,DC=COM” container
    • Describes how long a deleted object will not be restorable

 

Get Tombstone Lifetime:

 

Write-Output “Get Tombstone Setting `r”
Import-Module ActiveDirectory

 

$ADForestconfigurationNamingContext = (Get-ADRootDSE).configurationNamingContext

 

$DirectoryServicesConfigPartition = Get-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,$ADForestconfigurationNamingContext” -Partition $ADForestconfigurationNamingContext -Properties *

 

$TombstoneLifetime = $DirectoryServicesConfigPartition.tombstoneLifetime

 

Write-Output “Active Directory’s Tombstone Lifetime is set to $TombstoneLifetime days `r “

Note that no value returned means the tombstone lifetime setting is set to 60 days (default for AD forests installed with Windows 2003 or older).

Set Tombstone Lifetime to 365 days (for example):
Import-Module ActiveDirectory
$ADForestconfigurationNamingContext = (Get-ADRootDSE).configurationNamingContext

Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,$ADForestconfigurationNamingContext” -Partition $ADForestconfigurationNamingContext -Replace @{tombstonelifetime=’365′}

This same process can be leveraged to identify the msDS-deletedObjectLifetime value (180 days by default).

 

References:

May 22 2014

Microsoft TechEd 2014 Sessions Posted

One of the toughest parts of being in the IT field is staying up to date with technology trends, directions, and products. I have found that free-to-view online content is a great way to do this.
Microsoft has TechEd sessions posted going back to 2008:
Here are some sessions from Microsoft TechEd 2014 I find interesting:

Continue reading

May 22 2014

Virtualization Updates to Active Directory 2012

As part of the many updates to Active Directory, one of the most interesting is virtualization safeguarding in Windows Server 2012.

Active Directory Domain Controllers running Windows Server 2012 can now identify if they are virtualized and have been improperly restored or cloned (copied). Windows Server 2012 introduces a new feature called the VM Generation ID which is used to track the virtual machine (VM) on which the OS is running. When a new VM is created in a hypervisor that supports the feature (Hyper-V 2012 & VMWare vSphere 5.1), a VM Generation ID is created by the hypervisor and associated with the VM as the unique VM guest identifier. The VM Generation ID is a 128-bit cryptographically random  integer that changes when the VM’s configuration file changes. The virtual machine’s BIOS provides the VM Generation ID to the OS in an 8-byte aligned buffer in guest RAM, ROM, or device memory space which can be queried via ACPI namspace with a compatible ID of “VM Gen Counter” (also a DOS Device Name of “VM_Gen_Counter”. When the generation ID changes, there is an ACPI Notify operation on the generation ID device ID device using notification code 0x80 (an ACPI GPE can triger this notification).

Each Domain Controller has a unique identifier called the Invocation ID for the Active Directory database instance on that DC. When a DC is backed up and restored, the Invocation ID changes. Each DC tracks changes it makes to its local AD database, NTDS.dit, using an incremental counter called the Update Sequence Number (USN). Active Directory replication leverages a combination of the InvocationID and the USN in order to determine what data a DC requests from other DCs. The USN normally only increases in value; however, there are circumstances where a “USN rollback” occurs such as when a DC’s VM snapshot is restored. With a USN roollback, the DC is improperly restored to a point in time “rolling back” the USN to a previous value. The DC doesn’t have AD data that other DCs have and believe that it has (for more information, read my article on the subject: USN rollback). The new VM Generation ID protects against this scenario.

At first boot-up, a virtualized Windows Server 2012 Domain Controller queries the hypervisor for the VM Generation ID and stores it in in the Active Directory database file (NTDS.dit). Each time the DC is rebooted, the VM’s current VM Generation ID is compared with the value in the DC’s NTDS.dit file (ms-DS-Generation-Id). If the values are different, the DC resets the invocation ID, discards the RID pool, and updates the value in the DC’s NTDS.dit file.  The DC also non-authoritatively synchronizes the SYSVOL folder to ensure proper operation and replication.

NOTE: The ms-DS-Generation-Id computer attribute does not replicate – to view a specific DC’s Generation ID, query for it on that DC.

Here’s the value when viewed in ADUC on the DC:
DC2012-MSDS-GenerationID

Powershell command to view the VM Generation ID associated with a 2012 DC:
Import-module activedirectory ;
(Get-ADObject “CN=MCLABDC01,OU=Domain Controllers,DC=MCLAB,DC=net” -server mclabdc01.mclab.net -property msds-generationid).’msds-generationid’

 

You may notice in the graphic above that when querying DC02 for DC01’s msds-generationid attribute value, it is blank. Since this value does not replicate, you have to query for the value on the DC that stores the value.

This feature also provides the capability to clone (copy) Domain Controllers.

Scenarios where the VM Generation ID is changed:

  • Virtual machine starts executing a snapshot.
  • Virtual machine is recovered from a backup.
  • Virtual machine is failed over in a disaster recovery environment.
  • Virtual machine is imported, copied, or cloned.
  • Virtual machine’s configuration changes (depending on change).
  • Virtual machine is moved from a hypervisor host not supporting VM Generation ID to one that does.

Only Domain Controllers running Windows Server 2012 on a Hyper-V 2012 or VMWare vSphere 5.1 VM support this feature.

VMWare VM-Generation-ID support:

  • VMware vSphere 5.0 Update 2 (vCenter Server and ESXi must both be at 5.0 Update 2)
  • VMware vSphere 5.1 (ESXi must be at least 5.0 Update 2)

Some key caveats:

With this new capability come several requirements and limitations:

* A restored domain controller must be able to contact a writable DC.

If restored, a domain controller must have connectivity to a writable domain controller; a read-only domain controller cannot send the delta of updates. The topology is likely correct for this already, as a writable domain controller always needed a writable partner. However, if all writable domain controllers are restoring simultaneously, none of them can find a valid source. The same goes if the writable domain controllers are offline for maintenance or otherwise unreachable through the network.

* All domain controllers in a domain must not be restored simultaneously.

If all snapshots restore at once, Active Directory replication works normally but SYSVOL replication halts. The restore architecture of FRS and DFSR require setting their replica instance to non-authoritative sync mode. If all domain controllers restore at once, and each domain controller marks itself non-authoritative for SYSVOL, they all will then try to synchronize group policies and scripts from an authoritative partner; at that point, though, all partners are also non-authoritative.

* Any changes originating from a restored domain controller that have not yet replicated outbound since the snapshot was taken are lost forever.

Here’s an excerpt from Microsoft Article: Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100):

Safe virtualization of domain controllers:

Virtual environments present unique challenges to distributed workloads that depend upon a logical clock-based replication scheme. AD DS replication, for example, uses a monotonically increasing value (known as a USN or Update Sequence Number) assigned to transactions on each domain controller. Each domain controller’s database instance is also given an identity, known as an InvocationID. The InvocationID of a domain controller and its USN together serve as a unique identifier associated with every write-transaction performed on each domain controller and must be unique within the forest.

AD DS replication uses InvocationID and USNs on each domain controller to determine what changes need to be replicated to other domain controllers. If a domain controller is rolled back in time outside of the domain controller’s awareness and a USN is reused for an entirely different transaction, replication will not converge because other domain controllers will believe they have already received the updates associated with the re-used USN under the context of that InvocationID.

For example, the following illustration shows the sequence of events that occurs in Windows Server 2008 R2 and earlier operating systems when USN rollback is detected on VDC2, the destination domain controller that is running on a virtual machine. In this illustration, the detection of USN rollback occurs on VDC2 when a replication partner detects that VDC2 has sent an up-to-dateness USN value that was seen previously by the replication partner, which indicates that VDC2’s database has rolled back in time improperly.

How replication can become inconsistent

A virtual machine (VM) makes it easy for hypervisor administrators to roll back a domain controller’s USNs (its logical clock) by, for example, applying a snapshot outside of the domain controller’s awareness. For more information about USN and USN rollback, including another illustration to demonstrate undetected instances of USN rollback, see USN and USN Rollback.

Beginning with Windows Server 2012, AD DS virtual domain controllers hosted on hypervisor platforms that expose an identifier called VM-Generation ID can detect and employ necessary safety measures to protect the AD DS environment if the virtual machine is rolled back in time by the application of a VM snapshot. The VM-GenerationID design uses a hypervisor-vendor independent mechanism to expose this identifier in the address space of the guest virtual machine, so the safe virtualization experience is consistently available of any hypervisor that supports VM-GenerationID. This identifier can be sampled by services and applications running inside the virtual machine to detect if a virtual machine has been rolled back in time.

During domain controller installation, AD DS initially stores the VM GenerationID identifier as part of the msDS-GenerationID attribute on the domain controller’s computer object in its database (often referred to as the directory information tree, or DIT). The VM GenerationID is independently tracked by a Windows driver inside the virtual machine.

When an administrator restores the virtual machine from a previous snapshot, the current value of the VM GenerationID from the virtual machine driver is compared against a value in the DIT.

If the two values are different, the invocationID is reset and the RID pool discarded thereby preventing USN re-use. If the values are the same, the transaction is committed as normal.

AD DS also compares the current value of the VM GenerationID from the virtual machine against the value in the DIT each time the domain controller is rebooted and, if different, it resets the invocationID, discards the RID pool and updates the DIT with the new value. It also non-authoritatively synchronizes the SYSVOL folder in order to complete safe restoration. This enables the safeguards to extend to the application of snapshots on VMs that were shutdown. These safeguards introduced in Windows Server 2012 enable AD DS administrators to benefit from the unique advantages of deploying and managing domain controllers in a virtualized environment.

The following illustration shows how virtualization safeguards are applied when the same USN rollback is detected on a virtualized domain controller that runs Windows Server 2012 on a hypervisor that supports VM-GenerationID.

Example of how virtualization safeguards work

In this case, when the hypervisor detects a change to VM-GenerationID value, virtualization safeguards are triggered, including the reset of the InvocationID for the virtualized DC (from A to B in the preceding example) and updating the VM-GenerationID value saved on the VM to match the new value (G2) stored by the hypervisor. The safeguards ensure that replication converges for both domain controllers.

With Windows Server 2012, AD DS employs safeguards on virtual domain controllers hosted on VM-GenerationID aware hypervisors and ensures that the accidental application of snapshots or other such hypervisor-enabled mechanisms that could ‘rollback’ a virtual machine’s state does not disrupt the AD DS environment (by preventing replication problems such as a USN bubble or lingering objects). However, restoring a domain controller by applying a virtual machine snapshot is not recommended as an alternative mechanism to backing up a domain controller. It is recommended that you continue to use Windows Server Backup or other VSS-writer based backup solutions.

References:

May 20 2014

Microsoft BlueHat Resources

Microsoft has their own internal employee security conference called “BlueHat“.
Here are session links from the past few years:

Continue reading

May 15 2014

Group Policy Preferences Password Vulnerability Now Patched

Looks like Microsoft finally removed the ability to set admin account passwords through GPP due to the Group Policy Preferences password  exposure vulnerability.

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

Because of the security concerns with storing passwords in Group Policy Preferences, Microsoft just released a security patch, MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege, that removes this functionality. Any passwords that were in Group Policy Preference xml files stored in SYSVOL before the patch are still in SYSVOL after MS14-025.

Note that this doesn’t remove the ability for Windows to perform this functionality, it only removes the ability to configure passwords in Group Policy Preferences through the GUI. In other words, the patch is for the RSAT – Server Admin Tools. This is impressive since it actually removes functionality which is something Microsoft is traditionally not fond of doing.

In July 2013,  I wrote about the vulnerability of managing passwords with Group Policy Preferences. Here’s the information:

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

Continue reading

May 15 2014

Active Directory Changes in Windows Server 2012

Active Directory, aka Directory Services, has been updated quite a bit in Windows Server 2012.

Here are some of the major updates:

Microsoft article: “What’s New in Active Directory Domain Services (AD DS)”

Microsoft WhitePaper: Windows Server 2012 Evaluation Guide (pdf download)