Windows Deployment – Advanced – Part 1. Performing Domain Joins Securely

In the first of this new multi-part series, I will show you how to take you Windows Deployment to the next level.

(For this series, we're assuming your running Server 2012 R2 with the latest updates, and the latest release of MDT 2013).

This article looks at locking down the os.deploy account that you use to automatically join computers to the domain.

So, let us improve the security of the mdt join account. This account which we have specified in CustomSettings.ini (Windows Deployment, Part 1: Configuring the Deployment Environment) and which is used by MDT to join the target computer to the domain.

If we leave this account as a 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 Domain Users can only join 10 computers to the domain.

In our initial article, we made the account a member of the domain admins group – of course, perfectly acceptable in a lab environment, but not so in the real world.

This is because of these three facts:

  • The domain admin password is visible in the customsettings.ini
  • The domain admin password is sent in plain text across the network
  • The domain admin password is temporarily stored on the remote pc

So, how do we overcome this??

Grant the appropriate permissions for the mdt join account to create and update computer accounts in Active Directory. In our demo, this user account is: OS.Deploy

First, find our OS.Deploy account within AD (Active Directory Users & Computers).

Make sure that this account is not a member of Domain Admins (or Enterprise Admins for that matter).

This account should be a member of ‘Domain Users’, and nothing more.


Within AD, select view, and make sure Advanced features is selected.


If you followed our previous guides, you should have already created an OU for your deployed computers (check your CustomSettings.ini in MDT 2013 if you have). If not, now’s the time to make one (don’t modify your built-in default computers container!).


Right click on your OU (in our case: Deploy) and select Properties.


Click on the Security tab, then select the Advanced button.


On the permissions tab, Click Add.


In the permission entry dialog box, select principle.

In our case: OS.Deploy

This is the user account that will appear in your CustomSettings.ini (for simplicity I have selected a user account, though best practice would be to create a new security group, and add the OS.Deploy user account to that).

Make sure Type is set to: Allow

Applies to is set to: This object and all descendant objects.

Add (select):

  • Create computer objects
  • Delete computer objects

Click ok


Click Add again and add a second permissions entry for your mdt join account (OS.Deploy).

Assign Allow permissions (with scope set to Descendant Computer Objects) as follows:

  • Read all properties
  • Write all properties
  • Read permissions
  • Write permissions (under the second heading of permissions)
  • Change password
  • Reset password
  • Validated write to DNS host name
  • Validated write to service principal name

Click Apply / OK to close all open dialogs.

Your mdt join account should now be able to create new computer accounts and update these accounts as needed, without needing Domain Admin security rights.

If you hadn’t already created the Deploy OU as per the original tutorial, then pop onto your MDT deployment server and add this to your CustomSettings.ini file (using my demo as an example):

MachineObjectOU=OU= Deploy,DC=Cornwall,DC=local

(Open MDT, right click on the deployment share, properties, Rules tab).

Small hint for those who have far more complicated OU structures than my simple demo, with AD advanced view still ticked, right click on your “Deploy” OU, head over to the Attribute Editor tab, scroll down to distinguishedName.


Click View.

You can then Copy and Paste the string into your CustomSettings.ini file 😉


The next few articles in the advanced series will look at injecting the correct drivers for your system, and using WSUS to inject the latest patches into your images as they are building.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

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

Google photo

You are commenting using your Google 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 )

Connecting to %s