Active Directory User Account gets locked out when running VM's

[clh42]

I've done some searching on this and the only references I found were for the server products (ESX and the like) and talked about looking for services running under the user's account. Even though this is Workstation and player, I've checked the services and there's nothing trying to use an actual user's account.

I'm also sure it's not a cached credential within the VM because when we copy the exact same VM to another user's computer it locks out the AD account of whoever the user of that computer is. I'm the one who built the VM so if it was a cached credential it should lock out my account no matter who's running it.

This happens in both Workstation and Player. It happened originally under Workstation 6.5 and the Player version with that, and continues to happen after upgrading to Workstation 7 and the Player associated with that.

The basic issue is pretty much as the subject line says. We have a Windows XP VM built that we then copy to several different users' PCs who all run it. Some use Workstation to run it, some use Player. Randomly, and usually several times a day, when running the VM, the user's active directory user account that they're logged into their host PC gets locked out. Oddly, sometimes even after stopping using the VM for a while the user's AD account will continue to get locked out periodically even when not running the VM. But if the don't use the VM at all for a couple of days the problem goes away. The instant they use the VM again, it's guaranteed sometime that day their AD account will get locked out.

The VM is Windows XP Professional SP3. Updated with all patches. We do join the VM to the AD domain. When we copy it to a different PC we put a machine.id line in the vmx file that uniquely id's the VM to the host PC. When the user powers up the VM the first, there's a .vbs script that runs that reads the machine.id line and renames the VM computer name based on the machine.id from the .vmx file, then after the VM reboots, adds the VM to the AD domain.

The network adapter is running in bridged mode so the VM has direct access to the network.

This is just killing the benefit we're supposed to get from the VM when we have to keep having our AD accounts reset several times a day when using the VM.

Please, any ideas?

Thank you.

[clh42]

I forgot to mention, the hosts we're running on are also Windows XP Pro, and the host PC is also a memeber of the AD domain.

If there's any other information that would be helpful to have, let me know.

[golddiggie]

When you copy it to the new location, where the VM will reside and be run from, do you tell it that it's been copied to the new host system? Also, have you tried removing it from the domain, copy to the new host, rename it, then add it back into the domain?? In your AD configuration, how many logon attempts do you allow before locking the account? Make sure you've set the accounts to allow the user accounts to be logged in from more than one system at a time. Is the AD DC in mixed 2000/2003 mode, 2003 native, or 2008?

This really sounds like the issue is more on the domain side, than anything to do with VMware products. Especially since the issue spans more than one product, and version, and more than one host system. It could be the VM itself has the problem within it.

What AV product are you running? IF you're running the SAVCE, make sure you remove the GUID registry entry before you remove and then add it back into the domain.

VCP4

[clh42]

I have the option set in the .vmx file to always assume that the VM has been copied.

The VM "machine" is removed from the domain before it's shut down the final time before copying to other PC's. I set the VM back to a Workgroup, reboot it, make some final configs and shut it down, then copy it to the other host PC's. And as I said, when copied to the other host PC's, the "computer name" within the VM is changed to something unique based on each host PC's name before being joined back to the domain.

Our AD configuration allows 3 failed attempts before locking out. It does allow logging in from multiple PC's. One thing I also forgot to mention before is that within the VM we don't log in as ourselves. We log in with a generic test account. THAT ID does NOT get locked out. Only the user's account that's logged into the host PC gets locked out. (And just to see, we have tried logging in as ourselves inside the VM and it doen't make any difference.)

I'm not sure what mode AD is in. I know it's not mixed 2000/2003, but I'm not sure if we've transitioned to 2008 or not yet. I'm thinking we're in 2003 native.

Regarding the issue being with AD or the VM itself, I won't doubt it could be something in either, but it also has to be something regarding interaction within VMWare. The VM is based on a Ghost image that we've used for a long time, and still use, on physical PC's without any issues. Other than going from physical hardware the hardware drivers it used to use, going to VMWare Tools in the VM, there's nothing changed from the Ghost image to the VM.

Our AV is SAVCE version 10.1.5.5000 (they're working on upgrading to SEP 11 but aren't there quite yet). Can you be more specific about the GUID registry entry to delete before removing it from and adding it back to the domain? We don't do that with the Ghost image but I'll definitely give it a try for the VM.

Thank you.

[golddiggie]

Part of my pre-sysprep checklist when I was creating images where we used SAVCE 10.x was to remove the GUID entry from the following location in the registry:

HKey_Local_Machine

Software

Intel

LANDesk

VirusProtect

Current

The actual location might be slighly different for you. Since we always had the LANDesk Management Suite available to us. Although I believe the entry was the same even when I didn't install the agent on the image source system.

Another part of the process was to clear all system tools entries in the event viewer. I would suggest clearing ALL event log entries in the VM before you do the final power down and the copy to it's new home.

I would also stop all the Symantec services, especially the Antivirus and Antivirus Def services before the final shutdown. You might want to leave those off until after you've renamed the system. We also found that we had to completely kill the Microsoft Firewall service on the systems in order for them to reliably join the domain. You could get them to sometimes join with it running, but it was a crap shoot at times. Killing the service made the process run a lot smoother and was many times more reliable.

Since I've used the LANDesk imaging tools to capture, and deploy, system images I'll never go back to the ghetto Ghost tools...

VCP4

[clh42]

I do see the GUID registry setting for SAV. Thanks for directing me to it. Can you be more specific of the potential issues though by not deleting it, and could it really have an impact on this user account getting locked out issue? We've never deleted it on the Ghost images we use and have never had issues.

What's the reason for clearing the event viewer logs? Not that I'm opposed to doing it, but could it really have any impact on the user account getting locked out?

Never had any trouble on the Ghost images with not shutting down the SAV services either, but I can give it a shot.

We don't use Windows Firewall. It's disabled through policy on all of our images. We use a 3rd party firewall client. I'm sure this is not causing any issues. Never have trouble joining the PCs to the domain (in either the physical PC's with the Ghost image or the VM's).

[golddiggie]

Clearing that registry entry (or removing it) forces SAV to make a brand new one on next startup. Since you're changing the system name, and what it's residing on (even a virtual platform sees some of the actual hardware) you'll want the new UID generated. It does no harm at all, and has only provided benefits during any image deployment I've done (when I was at a SAVCE shop).

Clearing the logs, especially the security logs, also benefits the new system. Again, part of the BKM/best practices I followed during image captures.

I would still manually disable the Windows Firewall service even though it's handled by a policy. It's better to be 100% sure it's not missed than to not check it and it is being missed.

I have my 'cookbook' that I've used at two different companies now for image capture processes. The second one was shorter because we were not a SAVCE shop. Still, it's done very well for me over the years (reliably).

VCP4

[ANonMouse]

I experienced the same trouble once and found it was happening because of the stored creds on my workstation and not on the servers, although it is plausible this same thing could be applied to the server. My troubles started after a domain user password change. Since I am always connecting to a resource through RDP or a SMB share it would lock me out.

I wrote a script for this because I have hundreds of vm's I use across several domains and it's not easy to sift through and delete your credentials. Still, not many people have this problem so I will provide a simple solution below. Be careful not to delete everything in haste, you want to preserve things like github, docker, onedrive and other unrelated things like azure or other domain creds. So don't get lazy and choose to delete it all. I'll have to look up the script and post it here later but for now here is my simple solution.

Find and delete the offending credentials:

• Open an command window with Administrative privileges.
  • Find the offending credentials using the following command.
    • cmdkey /list
  • Decide which ones need to be deleted, usually by Target: LegacyGeneric:target=some-machine-server-etc
    • cmdkey /delete:some-machine-server-etc
  • What NOT to do? Don't delete all!

Another way to do this through a GUI using the Control Panel > Users. This is often disabled by the administrator but you can likely still call the function in keymgr.dll as shown here:

• Open a command Window with Administrative Privileges.
• Run the following command.
  • rundll32.exe keymgr.dll,KRShowKeyMgr
• Highlight the targets on the left side and either edit or remove them with the buttons on the right.