Machine domain accounts and snapshots

Every now and then this particular issue creeps into the forums.  A VM is reverted to a previous snapshot and domain membership is broken.  Or a new VM is created using a base image that is domain joined.  Or some other related scenario.

The first point to always remember is that a snapshot is a moment in time.  When you revert to a snapshot you go back to that previous moment in time and all of the settings that were active at that point in time (as far as the OS in the VM is concerned).

This most commonly manifests itself with machines that are domain joined at the time the snapshot was taken, then the machine runs for a period of time, during this time the machine account password is changed.  Thus when the VM is reverted to a previous snapshot the machine account password in the VM no longer matches the machine account password in Active Directory.

The machine is denied access to domain resources, but runs, it has a machine account in Active Directory.  Nothing looks out of place until the access denied behavior is noticed either by users or through trolling Event Logs.

There is some good background information from the Directory Services blog about machine accounts and Active Directory that you can review here:  Machine Account Password Process

There are two ways to deal with this situation:

1. Un-join the VM form the domain, delete the computer account from AD, and then re-join the Domain.
2. Prevent machine account password from changing prior to taking any snapshots: Disable machine account password changes

Keep in mind – the machine account passwords are designed to change silently in the background for a reason.  To prevent an un-trusted, malicious machine from impersonating a trusted machine and thus gaining access to your domain.  So don’t take changing this default behavior lightly.  By modifying this default behavior you are making a conscious decision to increase risk and decrease security in your environment.

Installing and configuring Test Agents when not in the same domain as the Test Controller

I think that the title says a lot in this case. 

I have a Team Foundation Server and I have a Test Controller registered to it. 

I also have Test Agents – they hang out in the lab (not in the production domain with the TFS Server or the Test Controller) so I need to have authenticated communication between the Agents and the Controller.

The most likely scenario is; the Test Controller is in the same domain as the TFS application server (assuming the TFS application server is in your production domain) and the Test Agents are not, nor is there a domain trust.

The Agents could be / should be in most any domain and most likely will execute their tests within an isolated test domain.

Installation and configuration of the Test Agent always requires local administrator rights, it is registration of the Test Agent with a remote Test Controller that can involve unique combinations.

If the Test Agent machine and the Test Controller machine are not joined to the same Active Directory domain or they are not joined to fully trusted domains (or the Agent machine is not domain joined) then:

1) Create local computer account on the Test Controller and each Test Agent machine to provide authentication.

2) This local account should have the same username and password across the Test Controller and Test Agent machines.

3) The “password never expires” check box should be checked.

4) When configuring the Test Agent username do not include the name of the local machine (machinename\username) use only the username (username).

Installation using the common local user account:

a. If this local user account is used to install the Test Agent software then the user account should be assigned to the local administrator security group of the Test Agent machine.

i. If this local user account is used to configure the Test Agent and register it with the Test Controller the local user account should be assigned to the local administrator security group on both the Test Agent and Test Controller machines.

Installation using an administrator account (not the common local user account):

1) The local administrator account can be used to install the Test Agent on the agent machine(s) as long as the local administrator user account password is the same on the Test Controller and Test Agent machines.