3

I set up an Windows Server VM on Azure last year and after having not logged in for a couple of months I tried to log in recently and strangely it told me my password was incorrect. I proceeded to reset the password, but that didn't work even though it said it was successful. I also tried the method presented here, but that didn't work either.

To be clear:

  • I do have access to the VM via Powershell, but resetting the password has no effect.
  • The VM is active and IIS services are responding normally.
  • RDP is enabled, the service is responding and the correct port is open.
  • Upon connecting and authenticating I get the "Your credentials did not work" message. This is even after supposedly resetting the password (double-checking the username and copy-pasting the password both into the Powershell window to reset and then the connection dialog).
  • I tried the machine name as a domain prefix (my-vm\username), as well as prefixing with a dot (.\username), nothing (\username) and the full Azure Profile name (myname.cloudapp.net\username).
  • the username is a plain alpha username, nothing curly there.
  • The passwords I've tried resetting it to should definitely meet complexity requirements: combining upper and lowercase, numeric and the usual non-alphanumeric characters you find in passwords, all more than 8 characters long. In addition I checked that no part of the username was in the password, and the password was not one that had been used previously (if that makes a difference).

So, what could be causing this? Have I missed anything? Are there any other steps can I try to regain access to this machine? Is the only step now to detach the disk and reattach to a new VM and manually copy everything across (which I'm trying to avoid)?

pcdev
  • 213
  • 1
  • 4
  • 12
  • Do you have ACL setup on the VM's network Endpoints that may be blocking you based on your source IP address? Note that you can perform PAT on Endpoints so it may be that you set this up to use a port other than 3389? – Simon W Jan 16 '15 at 05:25

2 Answers2

2

Check the date and time on your VM and your local machine to make sure that everything is set correctly. If you've manually set the clock on either and they are not in sync, it can cause problems with the authentication.

IceMage
  • 1,336
  • 7
  • 12
  • Because getting the time zone info on powershell isn't a straightforward thing (for me at least) - http://blogs.technet.com/b/heyscriptingguy/archive/2012/03/28/use-powershell-to-see-time-zone-information-on-remote-computers.aspx – IceMage Jan 05 '15 at 22:44
  • Thanks - It's unlikely that's the cause, but I can't check it in any case. Both methods mentioned in the link above require the use of machine credentials... which are no longer valid. – pcdev Jan 06 '15 at 11:19
  • 1
    ... and my local machine's clock and timezone is correct – pcdev Jan 06 '15 at 11:19
  • You actually only have to ensure they MATCH. You should be able to get read only access to that information if you have powershell access, and then adjust your local clock to match. Doesn't seem like this is your problem though, let me do some more digging. – IceMage Jan 08 '15 at 16:14
  • Can you upload any files? You should check a few properties, such as account lockout. If the account is locked due to bad password attempts, changing the password won't necessarily unlock it, or that the account has somehow become disabled. – IceMage Jan 08 '15 at 16:16
  • http://ss64.com/ps/unlock-adaccount.html – IceMage Jan 08 '15 at 16:30
1

OK, so luckily I wasn't in too much of a hurry to log into this machine, so over the past few weeks I've been thinking of other ways to get in. In case anyone else has this problem, here's a compiled list of ways I've thought of or found to regain access to a VM that is not responding:

  • Reset password as per the links in my original question (if lost password, locked account, unknown username, etc). This will change the username to the specified username, set the password and unlock the account. Except when it doesn't.
  • Remote install VNC (eg. if RDP service is broken). Good if the password works but you can't RDP in for some reason. Make sure you remove the self-signed certificate from the certificate store if you use this method.
  • Delete VM (using "Keep existing disks"), and recreate the VM, re-attaching the old disks (eg. if VM configuration is corrupted)
  • Delete VM (keep disks) and attach disks to another Windows instance to check disk integrity, scan for viruses, etc. Recreate instance using the detached disks.
  • Delete VM (keep disks) and attach to a Linux instance (don't initialize the disk as this link outlines!!), then use offline Linux tools to repair any problems.

I used the last method to finally gain access to my VM. Here are the detailed steps, as I haven't seen them elsewhere:

  1. Create a new low spec Ubuntu machine in the same region as the faulty Windows one.
  2. SSH into the box and issue the following commands:

sudo apt-get install chntpw

(confirm if required)

  1. Mount the Windows VHD to the Linux VM using the Azure Management Portal, then enter these commands on the console:

sudo grep SCSI /var/log/syslog

This will give you an idea of where your disk is located in the /dev directory: look for the last disks to be mounted, mine was sdc. If your windows disk has one main partition (like the C: of my VHD did), then you want to mount sdc1:

sudo mkdir /mnt/win

sudo mount /dev/sdc1 /mnt/win

If this was successful, you should now be able to see your Windows root folder by entering:

ls -l /mnt/win

  1. To use the password recovery tool we installed (chntpw), we need to change directory to where the main SAM registry hive is:

cd /mnt/win/Windows/System32/config

(remember Linux is case sensitive, even on Windows drives)

  1. Then start the password recovery tool on the SAM hive:

sudo chntpw -i SAM

This will take you into the interactive password tool and registry editor. Type ? to get help, l to list users in the SAM file, you can choose a user, reset the password to blank, unlock the account, etc. It's fairly self explanatory. Resetting the password is easy - the next step is harder though!

When you've finished updating the user account(s), quit (q) and write changes back to the SAM file.

  1. Because the password is now blank, and Windows by default doesn't allow blank passwords for remote logins, you also need to change a registry key to allow you to log in without a password. For this you need to load another hive and use the built in registry editor in chntpw (here's a helpful guide):

sudo chntpw -i SYSTEM

Select 9 for registry editor, then use the cd command to navigate to the right registry key and edit it:

cd CurrentControlSet

cd Control

cd Lsa

ed LimitBlankPasswordUse

Change the value to 0x0 and then press q to exit and make sure you write changes to the registry hive.

Now type sudo umount /dev/win then log off the SSH session and shut the linux VM down and detach the Windows VHD from the Linux VM.

  1. You're now ready to create a new azure VM from the old VHD disk, then cross your fingers and start the machine.

Note that this leaves the VM wide open to ANYONE to log in, so once the VM is reprovisioned and running you will need to immediately log in, set a new secure password, and re-enable the registry flag via regedit. For obscuritys' sake, you might want to create the VM with a different Cloud Service name, in case existing users stumble on the open RDP door before you do.

Good luck to any others who find themselves in this situation, and thanks @IceMage for your willingness to help!

Community
  • 1
pcdev
  • 213
  • 1
  • 4
  • 12