Sunday, August 11, 2013

Some Notes for a Certain Project

Just some scratch notes for a special project I am working on.

Nothing of interest for most other folks.

Remote Desktop and Automatic Login - Microsoft Visual Studio Forum

try using this
   mstsc /admin /v:ComputerName

or these
   mstsc /console /v:ComputerName

Be sure to “Log Off” rather than click the “X” to leave the session running if you aren’t coming back. Kinda like your mom telling you to shut the door behind you on the way out of the house when you were a kid. Heard it all the time…

Generally it seems you cannot use Microsoft’s Remote Desktop Connection service to establish an interactive remote control session with the logged in/active user’s desktop (session 0 ?)  unless you do it with the appropriate above arguments. However doing so may make a mess of things depending on how you exit…at least this appears to be my current understanding.

Just because you can doesn’t mean you should, and if you don’t log off properly…like I said you can make a mess for others coming behind you. If you find just such a mess, these tips might help clean things up.

In the end, RDC/RDP might be great or it might be messy.

If you are fortunate to be able to run UltraVNC services on some of your systems, you have some more options…especially if you are making a “headless” server box on a desktop OS platform. I’m personally more of a TightVNC guy myself but hey, close enough.

One of the problems might be that you want it to be a secure (AD/Domain) authenticated connection, but you don’t want someone to have to click “Allow/Disallow” on the headless system to approve that connection.

Fortunately there are options!

And then…

User Redge wrote:

configure and set MS Logon I or II required only at VNC server.
a) following the doc...
b) no if the UltraVNC setup was followed and exactly.
c) MS Logon I = Require MS Logon ... l#mslogon1
d) MS Logon II = New MS Logon ... l#mslogon2
Should set and required only at vnc server.
do not set vnc server as New MS Logon II on XP Home, won't work at all.

MSLogon can work, require turn OFF simple file sharing
windows XP

Open an Explorer window>Tools>Folder Options>View>The bottom check box

Headless systems are a pain…even if a modern BIOS can support booting without keyboard/mouse attached, and even if you can admin-pw lock the BIOS settings to prevent the USB ports from being active and used. Your system still may not boot if the NTLDR doesn’t see a proper video driver.

Headless System (Windows Embedded Standard 2009)  - Microsoft Developer Network post

In Windows Embedded Standard 2009 the support for headless devices starts with the availability of null-drivers for the standard MMI devices. Of course, the BIOS needs to support this kind of configuration, as well, but this should not be a problem on recent systems. The generic keyboard and mouse drivers in Standard are still present as well, when no hardware is connected, but the null driver for the VGA adapter needs to be added to the configuration. This requires the following components:

VGA Save could be left out, if there really is no VGA compatible chip on the board. This will create a dependency error, which in this case can be disregarded. Nevertheless, the benefit of having VGA Save in the image is that any time a graphics adapter card is plugged into the system VGA Save gets loaded instead of the Headless VGA driver. This enables screen output e.g. for field personnel troubleshooting the device. The VGA Boot Driver is required by NTLDR at boot time.

One last element,

The BIOS should be configured to “re-spawn” like a good digital soldier in the event that the power is lost (even a UPS dies if power is off too long) or if someone hits the Power-off button perchance.

Likewise, if the Windows system is NOT on an AD Domain, and logging into a local workstation/workgroup account profile, then you lock it down pretty well (to the bare minimums to function, and enable the auto-login to the set profile: Tip: Auto-Login Your Windows 7 User Account | Cool Stuff | Channel 9. Pretty easy stuff for the auto-login.

The challenge comes up if you want to add it to the AD Domain and use a domain-based account for security/auditing purposes.

There are a number of ways to do this, each with their nuances. Some work better than others. Some are more secure than others. Consider the risk carefully before choosing grasshopper!

[SOLVED] Windows 7 - Auto Logon With Domain Computer - post.  Easy enough with this registry-based solution BUT the user account and password are stored in the registry in clear-text.  You can roll your own .REG files for deployment with this method. However this could be a big security risk!

WindowsAutoLogin - freeware - IntelliAdmin. One nice feature of this application is that you can also control the number of times it allows an auto-login to occur and then after that “X” number of logins specified, it becomes disabled. That could be handy for some unattended (but brief) service events that require multiple reboots.

Autologon - Microsoft Sysinternals - Much better and easy enough to use. Per this post Safely setting autologon for Windows from the “Confessions of a Microsoft Consultant” TechNet Blog, we learn that AutoLogin saves the account/password string in the registry as a LSA secret.  That’s better than storing it in the Registry in plain-text, but it still is “easy enough” to penetrate and capture:

Autologon - commercial product from LogonExpert . I haven’t tried this product but it says it stores the logon information encrypted in AES 256, interacting directly with the WinLogon service to ensure nothing can grab the data. It has some really, really neat features.  The author has an overview of Free Solutions like what I have outlined above, as well as a Learn More about the product. There is an active download link from the page but I’m not sure if it is a limited-trial version or what. This may be a product that can provide both the “setup” features to enable AD-based auto-login and the security-needed for implementation. I’m really intrigued by this particular product.

Use this information wisely!

--Claus Valca

No comments: