I'm not 100% positive on this but I would re-think the way you want to access and use a more secure password (not that the complexity matters if you have physical access to crack the SAM file). I would look into teamviewer or logmein, both offer free solutions for remoting in. Also both teamviewer and logmein have android apps to remote in from your phone or tablet. Personally I like logmein, it has decent logging and reporting features even on the free accounts (I have it installed on over 150+ machines, you just don't have the ability to transfer files with the free version) If these ideas won't work for your application let me know in more specifics what and how you want to design the infrastructure.
I'm sorry that my above answer was displeasing to some I was only wanting to offer a known alternative solution without having to reload the operating system.
I've converted a test box to try this out for myself.
under, start/windows button, right click computer and then left click properties. This will open up your system properties or press the windows key + Pause/Break will get you there as well. on the left click "Advanced System Properties". Under the remote tab you have 3 options:
- Don't Allow Connections to this computer
- Allow Connections from computers running ANY version of Remote Desktop (less secure)
- Allow Connections from computers running Remote Desktop with Network Level Authentication (more secure)
I'm assuming that the second option might be selected. I would reccomend the third option and define the account that will have access and all other credentials would be denied.
Both options 2 and 3 work on my win 7 test box without any issues. Have you ran system file checker to see if there is a corrupted file screwing things up? To do this run a command prompt as administrator and run "sfc /scannow" without the quotes. If you need more info on the system file checker check out: http://support.microsoft.com/kb/929833
Another item to consider is that when RDP is running you lock the machine of the local user and run your own session. I don't know if this is an issue for you or not.
One other thing to look into is if group policy get set to allow any access with or without passwords by running gpedit.msc and browse to Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Accounts and take a look at how things are configured.