We have a domain-join approach that has worked well for us. I’ll share a generic overview of the process.
First take the time to set up OpenSSL encrypted passwords on the example of Bigfix Lab’s Local User Management. See this thread and this thread for some additional background on setting that up.
Create an OpenSSL key pair with parameters and strength to suit your requirements. Package and distribute one half of the pair.
It is highly recommended to create a special purpose AD service account that is only for domain joining. We create a suitable OU structure for the new systems in AD, then edit advanced permissions on the desired OUs, and add the AD join service account with only ‘Reset Password’, ‘Delete all child objects’, ‘Create Computer Objects’, and ‘Delete Computer Objects’ for this and descendant OUs. No other permissions. Domain Admin is not needed.
If desired, create sub-OUs based on organization structure, machine roles, location, etc.
Develop strong naming conventions based on those criteria (org structure, machine roles, locations, etc.).
Create a strong password for the service account and OpenSSL encrypt it with the non-distributed portion of the OpenSSL key pair that was created previously.
Then create the actual join script itself. You would use either powershell or netdom. This example uses netdom. You can nest the if-then-else logic as suitable for your organization. We have a fairly detailed script that places computers based on location, brand, machine type, machine role, and naming convention into specific OUs that have policies tailored for them.
// Creates parameter to the location of previously set up OpenSSL client components
parameter "OPENSSL" = "{pathname of parent folder of client}\openSSL\bin"
delete "{parameter "OPENSSL"}\join.bat"
delete "{parameter "OPENSSL"}\dat.raw"
// Takes a base64 encoded password file and decodes, then decrypts it into a temporary working file.
waithidden "{parameter "OPENSSL"}\openssl.exe" base64 -d -in "{parameter "OPENSSL"}\Base64EncodedEncryptedPassword.ssl" -out "{parameter "OPENSSL"}\BinaryEncryptedPassword.ssl"
waithidden "{parameter "OPENSSL"}\openssl.exe" rsautl -decrypt -inkey "{parameter "OPENSSL"}\PreDistributedHalfOfKeyPair.pem" -in "{parameter "OPENSSL"}\BinaryEncryptedPassword.ssl" -out "{parameter "OPENSSL"}\dat.raw"
delete __appendfile
delete "{parameter "OPENSSL"}\join.bat"
appendfile @ECHO OFF
appendfile SETLOCAL
appendfile set /p pwd= < "{parameter "OPENSSL"}\dat.raw"
if {computer name contains case insensitive regex "regex of location ABC"}
if {relevance for determining that machine role is role 'A'}
appendfile netdom.exe join %computername% /Domain:yourdomain.com /OU:"OU=valueA,OU=locationABC,DC=somevalue,DC=somevalue" /UserD:domain\svracct /PasswordD:%pwd%
elseif {relevance for determining that machine role is role 'B'}
appendfile netdom.exe join %computername% /Domain:yourdomain.com /OU:"OU=valueB,OU=locationABC,DC=somevalue,DC=somevalue" /UserD:domain\svracct /PasswordD:%pwd%
endif
elseif {computer name contains case insensitive regex "regex of location XYZ"}
if {relevance for determining that machine role is role 'A'}
appendfile netdom.exe join %computername% /Domain:yourdomain.com /OU:"OU=valueA,OU=locationXYZ,DC=somevalue,DC=somevalue" /UserD:domain\svracct /PasswordD:%pwd%
elseif {relevance for determining that machine role is role 'B'}
appendfile netdom.exe join %computername% /Domain:yourdomain.com /OU:"OU=valueB,OU=locationXYZ,DC=somevalue,DC=somevalue" /UserD:domain\svracct /PasswordD:%pwd%
endif
endif
move __appendfile "{parameter "OPENSSL"}\join.bat"
waithidden "{parameter "OPENSSL"}\join.bat"
// Delete plain text password. Another good option is to use Sysinternals Sdelete to securely wipe any working files that contained the password.
delete "{parameter "OPENSSL"}\dat.raw"
delete "{parameter "OPENSSL"}\join.bat"
action requires restart
restart 60
A variation of this theme can be used to re-join a computer to the domain. Or you can also replace a computer with a new one of the same name (computer rebuild scenario) by also accounting for the AD repl interval.
This is the generic version of a process that my organization has used successfully to join thousands of computers to domains. It does take some thoughtful work to prepare, but it pays off. This approach can also be set as a policy action targeting dynamic groups of yet to be created computers. When a new computer comes online and checks into Bigfix (assuming site subscription enrollments etc are set up) it can auto domain join based on the relevance you set. A thoughtful and highly structured naming convention and other attributes to key off of is important.