Deploying Windows 7 – Part 21: Securing MDT (Part 2)

By /

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.

In the previous article of this series, we examined the security issues involving two user accounts used by MDT:

  • The account specified in Bootstrap.ini that is used by target computers to connect to the deployment share on your MDT server
  • The account specified in CustomSettings.ini that is used by target computers to join the domain at the completion of the install.

I indicated that in a simple lab environment it’s OK to use the default Administrator account for the domain for both of these purposes. However, for security reasons in your production environment you will probably want to use separate accounts for each of these purposes, and preferably ordinary Domain Users accounts instead of Domain Admins accounts. So what we did in the previous article is create two new Domain Users accounts: mdt_build for our Bootstrap.ini file and mdt_join for our CustomSettings.ini file. After doing this we updated our deployment share because our Bootstrap.ini file had changed, and then we burned the resulting LiteTouchPE_x64.iso file to CD media. If we then boot our target computers using this CD, MDT will deploy Windows 7 to them but any customizations entered into the MDT database won’t be applied and an SQL Connection error will result. The problem is that our new account CONTOSO\mdt_build has not been granted rights to access our MDT database using Windows Integrated Security. This present article shows you how to resolve this SQL issue, and it also describes how to ensure your domain-joins are (reasonably) secure.  

Installing SQL Server Management Studio

To modify access rights to the MDT database on our SQL Server, we can use SQL Server Management Studio. In this series of articles we are using SQL Server 2008 Express Edition SP1 which we installed on our MDT server in article 15 of this series. To do this, we will install Microsoft SQL Server 2008 Management Studio Express on an administrator workstation running Windows 7 and the use it to grant the necessary rights to our CONTOSO\mdt_build account. Microsoft SQL Server 2008 Management Studio Express is a free download from Microsoft.

Begin by double-clicking on the downloaded installation file SQLManagementStudio_x64_ENU.exe. Doing this brings up a warning dialog that you will need to install Service Pack 1 afterwards (Figure 1):


Figure 1: Step 1 of installing SQL Server 2008 Management Studio Express

Clicking Run Program opens the SQL Server Installation Center (Figure 2):


Figure 2: Step 2 of installing SQL Server 2008 Management Studio Express

Click Installation at the left to display the installation options (Figure 3):


Figure 3: Step 3 of installing SQL Server 2008 Management Studio Express

Clicking the first option on this page runs the Setup Support Rules to verify the install can proceed (Figure 4):


Figure 4: Step 4 of installing SQL Server 2008 Management Studio Express.

The next screen indicates that no product key is required for the install (Figure 5):


Figure 5: Step 5 of installing SQL Server 2008 Management Studio Express

Accept the EULA next, then click Install. The Setup Support Rules are installed (Figure 6):


Figure 6: Step 6 of installing SQL Server 2008 Management Studio Express

On the Feature Selection page, make sure Management Studio – Basic is selected (Figure 7):


Figure 7: Step 7 of installing SQL Server 2008 Management Studio Express

Proceed through the remaining steps until the install is complete (Figure 8):


Figure 8: Step 8 of installing SQL Server 2008 Management Studio Express

Now download SQL Server 2008 Service Pack 1 and double-click on the installation file SQLServer2008SP1-KB968369-x64-ENU to begin the installation. Once again the SQL Server Installation Center is displayed, and after clicking on the first option the Welcome page is displayed and Setup the Support Rules run (Figure 9):


Figure 9: installing SQL Server 2008 Service Pack 1

Then proceed through the installation of SP1 accepting all the defaults until the service pack has been installed.

Configuring Access Rights Using SQL Server Management Studio

Now let us use SQL Server Management Studio to configure the appropriate database access rights for the CONTOSO\mdt_build account. Begin by launching SQL Server Management Studio from the Start menu (Figure 10):


Figure 10: Launching SQL Server Management Studio

When the Connect To Server dialog appears, leave the Authentication method set at Windows Authentication (Figure 11):


Figure 11: The Connect To Server dialog

Click the Server Name field and then click Browse For More (Figure 12):


Figure 12: Selecting the server name

When the Browse For Servers dialog displays the available SQL Servers, select the local instance SQLEXPRESS that is installed on your MDT server (Figure 13):


Figure 13: Select the local instance SQLEXPRESS

Click OK to close the Browse For Servers dialog and return to the Connect To Server dialog. The instance SQLEXPRESS will be displayed as the SQL Server name (Figure 14):


Figure 14: The instance SQLEXPRESS is selected as the SQL Server name

Clicking Connect causes SQL Server Management to connect to the SQLEXPRESS instance on your MDT server and opens the Microsoft SQL Server Management Studio console (Figure 15):


Figure 15: The Microsoft SQL Server Management Studio console

In the Management Studio console, expand Security and then right-click on Logins and select New Login from the shortcut menu (Figure 16):


Figure 16: Creating a new login for your SQL Server

On the General page of the Login – New dialog, click Search and select the CONTOSO\mdt_build account from Active Directory. Once this is done, the account will be displayed in the Login Name field of this page. In addition, change the Default Database setting at the bottom of the page from master to MDT (since MDT was the name we gave to our database when we created it back in article 15 of this series). The General page of the Login – New dialog should now look like Figure 17:


Figure 17: General page after settings have been configured

Do not make any changes to the Server Roles page. On the User Mappings page, select the checkbox for MDT, then click the button and add CONTOSO\mdt_build as a user mapped to this login. Then select the checkbox for db_datareader to assign the db_datareader fixed database role to the CONTOSO\mdt_build account (Figure 18):


Figure 18: Assigning the db_datareader fixed database role for MDT to CONTOSO\mdt_build

Since members of the db_datareader fixed database role can read all data from all user tables, doing the above enables your target computers to access customizations in your MDT database.

Do not make any changes to the remaining two pages (Securables and Status) of the Login – New dialog. Clicking OK displays the new login you created (Figure 19):


Figure 19: The account CONTOSO\mdt_build has been granted read access to your MDT database

You can now use the MDT database again to deploy Windows 7 in a customized fashion to your target computers as described in earlier articles in this series.

Tip:
If you need to grant multiple user accounts access to you MDT database, you can create a security group to contain these accounts and then use the above procedure to assign the db_datareader fixed database role to the group.

Tip:
For more information concerning SQL Server database-level roles, see this page on MSDN.

Performing Domain-Joins Securely

Let us finish off by addressing the issue of the mdt_join account which we have specified in CustomSettings.ini and which is used by MDT to join the target computer to the domain. If we leave this account as an ordinary Domain User, then MDT will be able to join the first few computers it installs into the domain but then will fail to join any others. This is because by default any user account that belongs to the Authenticated Users built-in identity (such as mdt_join) has the Add Workstations To A Domain user right assigned to it, which means the account can create up to 10 computer accounts in the domain. So if you’re only deploying 10 computers, you’re in luck. Otherwise, to perform your domain-joins securely you can choose from one of the following ways to proceed:

Method 1 – Make your mdt_join account a member of the Domain Admins group. Then remove the DomainAdminPassword = <password> line from your CustomSettings.ini file. The result will be that your Lite Touch installs will no longer be completely automated, and you’ll have to walk around to each machine and type in the password for your mdt_join account when prompted for this (make sure no one is looking over your shoulder when you do this). More hassle, but more secure.

Method 2 – Make your mdt_join account a member of the Domain Admins group, do not make any changes to your CustomSettings.ini file, and ignore the security consequences that the domain-join credentials are transmitted in clear text over the network (and are temporarily stored in obfuscated form on each target computer during installation). If you choose this approach, it might be best to do your deployment on a weekend or evening when others aren’t around. For extra security, change the password of your mdt_join immediately after you’ve finished your deployment. Don’t forget to change the password in both Active Directory and in your CustomSettings.ini file.

Method 3 – Make your mdt_join account a member of the Domain Admins group. Omit the entire domain-join section (four lines) in your CustomSettings.ini file. Then in Deployment Workbench open the properties of the task sequence you are using, select the OS Info tab, and click Edit Unattend.xml to open the answer file MDT uses for deploying Windows using this task sequence. In the specialize pass, expand the Microsoft-Windows-UnattendedJoin component and configure the necessary settings in Identification and Credentials to join the target computer to the domain. The password you specify for the domain-join account here will be obfuscated but not encrypted, and the unattend.xml file will be cached on the target computer anyway during deployment, so this approach doesn’t make deployment any more secure.

Method 4 – Omit the entire domain-join section (four lines) in your CustomSettings.ini file and deploy your target computers into a workgroup instead of a domain. Then join the machines to the domain later on either by doing it manually on each machine (if you only deployed a dozen or so computers) or by running a netdom join script using Group Policy (if you have lots of computers) or by some other method.

Method 5 – Grant the appropriate permissions for the mdt_join account to create and update computer accounts in Active Directory. This approach allows you to leave the mdt_join account as an ordinary Domain Users account which solves our security problems, but it takes some careful work in order to implement. Briefly, the steps you will need to perform are as follows:

  1. Open the Active Directory Users and Computers console.
  2. Select the View menu, then toggle on Advanced Features.
  3. Create an organizational unit (for example DeployedComputers) that will contain the computer accounts of newly deployed computers. (This way you won’t have to modify the permissions on the default Computers container.)
  4. Open the properties of the DeployedComputers OU and select the Security tab.
  5. Click Advanced to open the Advanced Security Settings dialog for the OU.
  6. Click Add and add an ACE for your mdt_join account to the ACLs for this OU.
  7. In the Permission Entry dialog, assign Allow permissions (with scope set to This Object And All Descendant Objects) as follows:
    ·         Create computer objects
    ·         Delete computer objects
  8. Click OK, then click Add again and add a second ACE for your mdt_join account that assigns Allow permissions (with scope set to Descendant Computer Objects) as follows:
    ·         Read all properties
    ·         Write all properties
    ·         Read permissions
    ·         Write permissions
    ·         Change password
    ·         Reset password
    ·         Validated write to DNS host name
    ·         Validated write to service principal name
  9. Click OK repeatedly to close all open dialogs.











Your mdt_join account should now be able to create new computer accounts and update these accounts as needed even though mdt_join is not a member of the Domain Admins group. Finally, in order to fully automate domain-joins using MDT you will need to add the following line to your CustomSettings.ini file:

MachineObjectOU=OU= DeployedComputers,DC=CONTOSO,DC=COM

One final approach you could follow would be to carry all the client computers on your production network into your secure lab, deploy Windows on them, and then carry them back into the offices where they belong. If you decide upon this approach however, be careful you do not injure your back!

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

About The Author

Mitch Tulloch is Senior Editor of both WServerNews and FitITproNews and is a widely recognized expert on Windows Server and cloud technologies. He has written more than a thousand articles and has authored or been series editor for over 50 books for Microsoft Press and other publishers. Mitch has also been a twelve-time recipient of the Microsoft Most Valuable Professional (MVP) award in the technical category of Cloud and Datacenter Management. He currently runs an IT content development business in Winnipeg, Canada.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top