A lot of people have an opinion on the Offline Domain Join (ODJ) functionality in Windows Server 2008 R2 and Windows Server 2012 Active Directory, Windows 7 and Windows 8. Of course, everyone is entitled to an opinion, but sometimes fact checking is useful for a discussion.
To this point, I have captured the top 5 myths on ODJ from discussions I had with people on this subject throughout the last couple of years. You find them in this blogpost.
5. Only Domain Admins can provision
A default Active Directory environment will only allow members of the Domain Admins group to provision computer accounts for Offline Domain Join (ODJ). Changing this behavior, however, is fairly simple. The following methods can be used to allow lower-privileged accounts the required privileges:
- The user right to Add workstations to the domain can be set using Group Policy.
This method allows you to create computers in the default Computers container and in any organizational unit (OU) that is created later (if no Deny access control entries (ACEs) are added).
- The Access Control List (ACL) of the default Computers container for the domain can be edited to delegate the correct permissions. Alternatively, an OU can be created and its ACL edited to grant the Create child – Allow permission. In this case, the /machineOU parameter needs to be added to the djoin /provision command.
4. Offline Domain Join has specific AD requirements
Many people believe Offline Domain Join has specific requirements in terms of Domain Controller Operating System level, Domain Functional Level (DFL) and Forest Functional Level (FFL).
First of all, Offline Domain Join does not require a Domain Functional Level or Forest Functional Level. Offline Domain Join can be used in any Active Directory environments, but djoin.exe is only available on Windows Server 2008 R2, Windows Server 2012, Windows 7, Windows 8 and Windows RT. You will need to perform the djoin.exe commands from machines running these Operating systems.
The availability of djoin.exe on Windows RT is a mystery to me too.
If your environments feature Domain Controllers running versions of Windows Server earlier than Windows Server 2008 R2, you will need to add the /downlevel command line switch.
3. Offline Domain Join is utterly useless in real life
Microsoft has excluded a lot of functionality to keep a level of security to this solution. Therefore, a user cannot log on to an offline joined computer with a domain account before the computer has seen a Domain Controller. Sure, this poses a challenge.
In Windows 8 and Windows Server 2012, Offline Domain Join was significantly improved. Offline Domain Join really proves its worth with the ability to offline provision DirectAccess clients with certificates and group policies.
2. Offline Domain Join blobs are encrypted
Although, Offline Domain Join blobs are not human-readable, these files are not encrypted. They are merely encoded. You can easily decode them to a more human-readable format, without a password. … and if you can, so can anyone else.
When you Offline Domain Join a computer, on both the Domain side and the computer side, a computer password is set to match. The password for the computer account could be exposed on the computer side by decoding the blob, as shown here. It then can be used for malign purposes on the domain side. But, this is also true for regularly domain-joined computers for the same reasons. Point is you should monitor for unused computer accounts (read: computer accounts that have not changed their computer account password recently).
I feel Offline Domain Join, by default, is more secure than the domain join procedures of older Windows clients, because the first time an offline joined computer sees the domain it resets its computer account. Previously, regularly domain-joined Windows installations only trigger to change their passwords after 30 days, by default.
1. Offline Domain Join is hardly used
It’s true not a lot of companies are actively deploying workstations using a process that actually incorporates an offline ODJ. When you look at the log file for a domain join operation, you will see that, actually, every domain join is an offline domain join, streamlining the communication between Domain Controller(s) and clients.