Active Directory in a virtual machine--a problem and answer that may be overlooked for a long time

Written on the outside of the title

Many people today confuse the concept of virtualization and cloud computing, but the reality is that virtual machines have penetrated into large and small data centers and become "cornerstones" of a variety of businesses, possibly smaller than a test system, to a complete Hadoop cluster load. So in any case, the individual believes that deep practice of virtualization is necessary in the future that can be expected today.

Today I would like to discuss in more depth the issues that need to be noted in the Active Directory in virtual machines and how to resolve them through the Guardian services provided in Windows Server 2012.

The next blog will continue to complete the method of cloning and rapid replication of domain controllers in a virtual machine environment.

In fact, the Active Directory and domain controllers have existed in the virtualized world for many years, and therefore have accumulated many best practices, such as the technical articles detailing how to deploy domain controllers above Hyper-V.

The areas where careful design and consideration are needed are mainly focused on:

1. How to apply a snapshot to a domain controller in a virtual machine environment

2. Export to a virtual machine running a domain controller

3. copy domain controller virtual disk files such as VHD

I don't know, reader. Have you noticed the above questions and best practice tips, anyway, as a domain controller in the work to build the environment is indeed never pay attention to this problem; I suspect that many of the administrators of virtualized environments may well have overlooked this potential problem.

Before we start the discussion and answer the question, why do we have this problem? Isn't a snapshot a unique backup way for a virtual machine?

For this particular application of the Active Directory, there exists a replication relationship for the Active Directory, which is updated through a logical clock that is perceived and controlled, in the Active Directory The logical clock is called the USN (Update sequence number), and the USN is used to record the update sequence on each domain controller , each domain controller has its own unique identity change source, called invocationID.

As a result, snapshots are recovered and are prone to incorrect USN drift, and failure to perceive such changes is likely to cause problems that are commonly referred to as "USN bubbles" and produce such things as:

Residue objects

Inconsistent password

Inconsistent property values

Schema inconsistency when schema FSMO rollback

More serious problems may even result in the security topic SID being duplicated or invalidated, unauthorized resource access over a period of time, or ultimately affected users not being able to log in to the domain properly.

Look at the following scenario where there are two domain controllers (DC1 and DC2) in the domain,

1. In time T1, we created a snapshot on the DC1 virtual machine, at which point the USN is 100,DC invocationID is a, and the security principal Sid Pool is (unique ID in the domain) RID 500 to 1000.