Deploying Windows 7 - Part 20: Securing MDT (Part 1)

by [Published on 6 April 2010 / Last Updated on 6 April 2010]

This series of articles on deploying Windows 7 continues by describing some steps you can take to secure your MDT deployment environment.

If you would like to read previous articles in this series, please go to:

Tip:
You can find more information about automating LTI deployment in the Windows 7 Resource Kit from Microsoft Press. I am the lead author for this Resource Kit and I also maintain the Unofficial Support Site for the Windows 7 Resource Kit with answers to questions posted by readers, as well as links to the latest resources on Windows 7 deployment, administration and troubleshooting.

Credentials in Bootstrap.ini

I'll return to explaining how to configure and use the MDT database soon, but at this point I would like to bring up the issue of MDT security. So far in this series of articles on deploying Windows 7 we haven't been very concerned about security. For instance, the Bootstrap.ini file we have been using for our deployment share in these articles looks like this:

[Settings]
Priority=Default
[Default]
DeployRoot=\\SEA-DC1\DeploymentShare$
UserID=Administrator
UserDomain=CONTOSO
UserPassword=Pa$$w0rd
KeyboardLocale=en-US
SkipBDDWelcome=YES

The user account specified by the UserID, UserPassword and UserDomain properties in Bootstrap.ini is used by the Windows Deployment Wizard running on the target computer to connect to the deployment share on the MDT server and access the contents of this share. Until now we have been using the default Administrator account in the domain for this purpose. There are two reasons why this is not a good idea.

First, if you are initiating your Lite Touch (LTI) deployment manually by booting your target computers using your LiteTouchPE CD, you should be aware of the fact that your Bootstrap.ini file is actually present on this CD. To see this, let's begin by examining the contents of a LiteTouchPE CD in Windows Explorer (Figure 1):


Figure 1: Contents of a LiteTouchPE CD as viewed in in Windows Explorer

Note that most of the CD consists of a Windows image file Boot.wim, which is found in the \sources folder on your CD. (The \boot folder contains only some files used to enable the CD to boot and mount this image.) Now, let us say you left your LiteTouchPE CD lying around and someone stole it. The thief could then install Windows AIK 2.0 on a computer and mount the Boot.wim file on this CD to an empty folder using the Imagex command as follows (Figure 2):


Figure 2: Mounting the Boot.wim file from a LiteTouchPE CD

Once the Boot.wim file has been mounted to the empty folder (here named C:\PEbootfiles) the thief could then browse the contents of the mounted image using Windows Explorer (Figure 3):


Figure 3: Your Bootstrap.ini file is present in the Boot.wim file of your LiteTouchPE CD

The thief could then open Bootstrap.ini in Notepad (Figure 4):


Figure 4: This Bootstrap.ini file contains administrative credentials for your domain!

At this point your entire Windows infrastructure has been compromised since the thief has obtained Domain Admins credentials. So, if you are going to use Domain Admin credentials in your Bootstrap.ini file, you obviously need to protect your LiteTouchPE CD (or DVD or USB flash drive depending on the boot media you are using to initiate LTI deployment). In other words, do not let unauthorized persons have access to such media.

The other security issue concerns transmissions of credentials over the network. When you boot a target computer into Windows PE using your LiteTouchPE boot media, the computer typically acquires an IP from a DHCP server and then tries to establish a connection with the deployment share on your MDT server. Now, if you are using MDT in a New Computer scenario (that is, to perform a bare metal deployment onto a target computer that currently has no operating system) then Kerberos or NTLM authentication is used to securely pass the credentials indicated in the Bootstrap.ini file from the target computer to the MDT server, and someone sniffing the network would not be able to steal these credentials. But if you using MDT in a Refresh Computer scenario (that is, to re-image an existing computer and save/restore user state information) then Bootstrap.ini is processed from the deployment share and the credentials are passed over the network in clear text. This means that someone sniffing the network in this scenario could steal the credentials specified in Bootstrap.ini, and if these are Domain Admins credentials then your network is compromised.

Of course, if you're using MDT in a test environment or in a secure lab that mirrors your production network but has a different domain, then it's fine to leave the default Administrator account for the domain in Bootstrap.ini as shown in Figure 4 above. If you're using MDT in a production environment however, you probably don’t want to do this. We'll see one possible solution to this issue in a moment. 

Credentials in CustomSettings.ini

The other place credentials are specified in MDT is in the CustomSettings.ini file for your deployment share. Specifically, the following portion of a CustomSettings.ini file is used to automate the process of joining target computers to the domain during the final phase of deployment:

JoinDomain=CONTOSO
DomainAdmin=Administrator
DomainAdminDomain=CONTOSO
DomainAdminPassword=Pa$$w0rd

Note that we have been using the same account (CONTOSO\Administrator) in these articles for both Bootstrap.ini (to allow the target computer to access the deployment share) and CustomSettings.ini (to join the target computer to the domain once the install has completed). Now your CustomSettings.ini file is not present on your LiteTouchPE boot media, your Boostrap.ini file, so that's not an issue. But in all deployment scenarios where automated domain-join is performed, the above info contained in CustomSettings.ini is transmitted over the network from the MDT server to the target machine in clear text. This means that if you use a Domain Admins account to automatically join deployed computers to your domain, someone sniffing your network could easily compromise the security of your entire network. The problem however is that, generally speaking, admin-level credentials are required if you want to join a computer to a domain. There are some workarounds to this issue however as we'll shortly see. Once again however, if you're using MDT in a test environment or in a secure lab, you can leave the default Administrator account for the domain in CustomSettings.ini as shown above.

Using Separate Build and Join Accounts

If we are going to use our MDT server to deploy Windows in a production environment, the first thing we can do to make MDT more secure is to use separate user accounts for connecting to the deployment share and for joining computers to the domain. In this example we will create two new user accounts:

  • mdt_build This "build" account will be used to enable target computers to connect to our deployment share.
  • mdt_join This "join" account will be used to automatically join target computers to the domain as the deployment process finishes on the computers.

When you create these accounts in Active Directory Users and Computers, they are automatically assigned membership in the Domain Users group. Let's leave it at that for the moment—do not add these accounts to the Domain Admins group.

Now let us examine the ACLs on our deployment share. Figure 5 indicates that the Users group on the MDT server, which includes the Domain users group as a member, has Read & Execute permission on the share:


Figure 5: ACL of Users group for a deployment share

Now if all you are using this deployment share is for installing Windows on target computers, then Read & Execute permission is sufficient since it allows the target computer to read files contained in the share and run scripts and programs in the share. In other words, our build account, which is specified in Bootstrap.ini, can be a simple Domain Users account—it does not have to be a Domain Admins account. That is good news! So let's go ahead and change the account specified by the UserID property in our Bootstrap.ini file from Administrator to mdt_build. Once we've done this, our new Bootstrap.ini file looks like Figure 6:


Figure 6: Bootstrap.ini now specifies a Domain Users account

Do not forget that after you make changes to your Bootstrap.ini file you need to update your deployment share (Figure 7):


Figure 7: Always update your deployment share after modifying Bootstrap.ini

And do not forget also that after updating your deployment share you'll need to burn a new LiteTouchPE CD since the Bootstrap.ini file is included on it.

So far, so good. Now the issue of using the join account is a bit more complicated, so we'll get to this later. Meanwhile, I need to mention to you that the change you've just made in your Bootstrap.ini file has broken something for if you now try and configure your MDT database to deploy Windows differently to different computers based on the computer's UUID, MAC address, or other machine property as described earlier in Part 16 and Part 17 of this series, you'll discover that this no longer works! Specifically, you'll be able to deploy Windows 7 using MDT but any customizations you've specified in the MDT database won't be applied (and the target computer won't join the domain either). You may or may not see an error message displayed at the end of the deployment process, but either way if you later examine the BDD.log in the %WINDIR%\Temp\Deployment logs folder on a deployed target computer, you'll see the following error:

ZTI error opening SQL Connection: Cannot open database "MDT" requested by the login. The login failed. (-2147467259)

We will see how to fix this issue in the next article of this series where we'll also examine the issue of securely joining the domain as well.

If you would like to read previous articles in this series, please go to:

Featured Links