jump to navigation

Securing your installation of Litetouch MDT October 27, 2009

Posted by keithga in MDT 2010.
Tags: , ,
trackback

There are several instances during the litetouch deployment process where sensitive pieces of information are stored and retrieved as plaintext. The most common example of this is the Administrator Password.

The Administrator Password is typically gathered by the Deployment Wizard, stored locally in the c:\MININT\SMSOSD\OSDLOGS\VARIABLES.DAT file, and later set by ZTIConfigure.wsf and Litetouch.wsf.

I would be great if this data was encrypted during installation, however, that is not possible in all instances. The Administrator Password, for example, must be available as plaintext (unencrypted) for AutoLogon to work. And Windows AutoLogon does not itself encrypt the Administrator Password.

For MDT 2010, we added a new feature that obfuscates critical data in the variables.dat file using the same obfuscation method used by Windows in the Windows System Image Manager found in the WAIK. This data is not 100% secure, I know the method used to obfuscate the data, and I can easily read the information, however most users can’t. (Can you guess the algorithm? Don’t tell anyone :^)).

In most scenarios though, this shouldn’t be a problem. The user will type in a local password, the scripts will save the information locally, but the data is purged at the end of the Litetouch Deployment process.

There are ways that we *can* help protect sensitive information like the Administrator Password if required. One possible way is to get the user to input a “Less Secure” Administrator password at the start of the installation process. We can then inject at the end of the Litetouch deployment process a new step to auto-expire the administrator account’s password. Then the next time a user logs into the administrator’s account, they will be forced to change the password.

Forcing the user to change the password at the end of the Litetouch process has another advantage. When we start the Litetouch installation process for an OS (new computer), we are not joined to a domain. Meaning any Local Administrator Password complexity policies are not applied. If we force the user to change the password at the end of the install process, after the machine has been auto-joined to a domain, then we can enforce any Complexity Requirements required by the domain.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group
Advertisements

Comments»

1. tmintner - March 3, 2010

Hello,

With MDT 2010, MDT obfuscates the variables that are sensitive in variables.dat automatically such as anything with a username or product key.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: