Welcome to Dirteam.com/ActiveDir.org Blogs Sign in | Join | Help

The things that are better left unspoken

a blog by Sander Berkouwer

Related

AD Manager Plus
 

Blog roll

News



Archives

New features in Active Directory Domain Services in Windows Server 2012, Part 19: Offline Domain Join Improvements

With Windows 7 and Windows Server 2008 R2 Microsoft introduced a new Active Directory feature called Offline Domain Join (ODJ). This feature allows for clients to be joined to an Active Directory domain, without the need of having a direct connection to any of the Domain Controllers for the Active Directory domain.

Scenarios

Offline Domain Joins use useful when you want to join a computer to an Active Directory infrastructure without the need for direct communication between the client and a Domain Controller. These include:

  • Deploying vast amounts of computers, without straining Domain Controllers in terms of bandwidth and processing, which might affect existing domain-joined computers. Also, in this scenario Offline Domain Join saves time.
  • Deploying domain-joined computers to a branch office site where only Read-only Domain Controllers reside. (Read-only Domain Controllers are not suitable for clients joining the domain)
  • Deploying domain-joined computers to users in remote locations (like homes) that from time to time require access to resources in an Active Directory environment and may not have a high enough quality connection to the Domain Controllers.

Although Offline Domain Join can be used to join computers to a domain without a direct connection to an Active Directory infrastructure, at one point a domain-joined computer needs to connect to a Domain Controller on a regular basis to stay a part of the Active Directory infrastructure. (unless you want to spend the rest of the lifetime of the domain-joined computer feeding it offline domain join information…)

     

What’s New

Offline Domain Join has been extended by allowing the blob to accommodate Direct Access prerequisites:

  • Root Certificates
  • Certificates
  • Group Policies

This means the number of scenarios increase. One of the main scenarios that now gets included is deploying domain-joined computers to DirectAccess users. The clients now have everything they need to successfully connect to the DirectAccess server(s).

Note:
A Graphical User Interface to perform Offline Domain Joins is not part of the improvements to Offline Domain Join in Windows 8 or Windows Server 2012.

     

Performing Offline Domain Joins

Let’s look at the individual steps of the process:

Step 1

To kick off the Offline Domain Join an administrator would logon to the Windows Server 2012-based Domain Controller. When logged on with an account with sufficient permission and quota to create Computer Accounts, the administrator would provision the client on the Domain Controller itself with the following command:

djoin.exe /PROVISION /DOMAIN DomainName /MACHINE MachineName /SAVEFILE FileLocation

Here’s an example:

djoin.exe /PROVISION /DOMAIN domain.local /MACHINE Win8-2
/SAVEFILE C:\ODJBlobs\Win8-2.b64

Now, In situations where you’d want to include Root Certificates, Certificates or Group Policies in the blob, extend the command above with the following extra switches:

Include root certificates /RootCACerts
Include certificate templates (includes their root certificates) /CertTemplate
Include Group Policies /PolicyNames

An example of such a command would be:

djoin.exe /PROVISION /DOMAIN domain.local /MACHINE Win8-3
/POLICYNAMES CompanyLookAndFeel
/SAVEFILE C:\ODJBlobs\Win8-3.b64

    

Step 2

This command, when successful, creates the in the location specified. This file, which can be given any file extension is a Base64-encoded file, containing all the necessary information for a Windows 7 client to join the Active Directory domain.

When you open the file and pull it through a base64-decoder (like this one) the contents of the file become clear.

Inside the blob

Let’s take a look at the Offline Domain Join blob we created in step 1 for Win803 in the domain.local domain:

Sample Offline Domain Join Blob (original screenshot)


This file doesn’t really provide any insight into how Offline Domain Join works its magic, but as mentioned earlier, the Offline Domain Join (ODJ) blob is a base64 encoded file. This means we can put it through a Base64 decoder like this one, or convert it using one of the many online base64 decoders. This will result in outcome similar to the text file below:

Sample decoded Offline Domain Join blob (original screenshot)

As you can clearly see, the decoded file contains the information you’d suspect a client needs to join the domain. The decoded file contains the DNS domain name (domain.local), the workstation NetBIOS name (Win8-02), the computer password, the NetBIOS domain name (DOMAIN), the name of the Domain Controller (DC01.domain.local), it’s IPv4 address (10.8.255.1) and the Active Directory site. (Default-First-Site-Name). Also, it includes the policy settings in the CompanyLookAndFeel Group Policy.

The nature of the decoded file, also warrants the security note placed in the Offline Domain Join (Djoin.exe) Step-by-Step Guide:

The base64-encoded metadata blob that is created by the provisioning command contains very sensitive data. It should be treated just as securely as a plaintext password. The blob contains the machine account password and other information about the domain, including the domain name, the name of a domain controller, the security ID (SID) of the domain, and so on. If the blob is being transported physically or over the network, care must be taken to transport it securely.

  

Step 3

After the Offline Domain Join blob gets transferred to the would-be client, a local administrator can join the computer to the domain in an offline fashion by typing the following command in an (elevated) command prompt:

djoin.exe /REQUESTODJ /LOADFILE FileLocation /WINDOWSPATH WindowsPath /LOCALOS

As an example, here’s the command for Win8-03:

djoin.exe /REQUESTODJ /LOADFILE C:\Win8-03.b64
/WINDOWSPATH C:\Windows /LOCALOS

Note:
Alternatively, you can include the Offline Domain Join blob in an unattend.xml file.

After the client successfully works through the command, the would-be client reboots as a member of the Active Directory domain. On first contact between the client and the Active Directory domain, the client would reset its Computer Account password.

   

Requirements

Operating system requirements

Offline Domain Join requires Djoin.exe. This command is available on domain-joinable editions of Windows 7 (Professional, Ultimate, Enterprise), domain-joinable editions of Windows 8 (Professional, Enterprise), Windows Server 2008 R2 and Windows Server 2012.

Note:
When you want to include root certificates, certificate templates and group policies, you will need to run djoin.exe on Windows 8 or Windows Server 2012.

If you want to use djoin.exe with Windows Server 2008-based Domain Controllers, use the /downlevel switch when you provisioning.

credential requirements

The djoin.exe command needs to be run by a user account with sufficient permissions to create computer accounts. By default, members of the Domain Admins group can create computer accounts. The user right to Add workstations to the domain can be set using Group Policy, or can be granularly delegated using Active Directory Delegation of Control.

     

Concluding

Offline Domain Join (ODJ) already was a nice feature in Windows 7 and Windows Server 2008 R2, but in Windows 8 and Windows Server 2012 this feature really proves its worth with the ability to offline provision DirectAccess clients with certificates and group policies.

Further reading

Offline Domain Join (Djoin.exe) Step-by-Step Guide (Online version)
What's New in AD DS: Offline Domain Join
Windows 2008R2 features part I: Offline domain join
Windows 2008R2 features part I: Offline domain join
How do I perform an offline domain join in Windows Server 2008 R2 ?
Windows Server 2008 R2: Offline Domain Join Step-by-Step Guide
Requirements when Joining a Domain
Domain Users Cannot Join Workstation or Server to a Domain
Will Windows 7’s “offline domain join” finally rid us of all the third party “fast sysprep” functions? No :(

Comments

erntsnst said:

hi sander -- great article.

i am curious how this experience scales in an enterprise. for example, i don't see myself logging into a domain controller to issue offline domain joins. in fact, i see that as a delegated role to people who are closer to the action -- as in desktop support individuals who would be working these "man in a cave" scenarios.

any thoughts around that?

# October 4, 2012 3:33 PM

Sander Berkouwer said:

Microsoft seems to have had extensibility high on the list when they created this feature. The feature's main capability is it wraps the reply from a Domain Controller into a single file, that can be fed to a proposed Active Directory member.

For small environments, the current implementation with the non-PowerShell djoin.exe command and the non-encrypted blob will suffice.

For larger environments, though, a lot of scripting can be wrapped around this feature to make this work with current procedures and products. System Center Orchestrator, which is a part of System Center 2012, seems to a good candidate to make Offline Domain Join work in larger environments, but any person can script their own solution based on their favorite scripting language.

# October 4, 2012 4:50 PM

CypherBit said:

If we use the djoin.exe on Windows 8/2012 computer, can we also use the new functionality of DA,certificates on Windows 7?

# November 6, 2012 10:00 PM

Sander Berkouwer said:

Hi CypherBit,

I haven't looked into backward compatibility for this feature yet.

# November 9, 2012 7:38 AM
Anonymous comments are disabled