Fixlet help: Invoke - Join Active Directory Domain - Windows

Content Authoring BigFix.me
1

Need help to set this up please. What changes should I make to use this in our environment?

Invoke - Join Active Directory Domain - Windows
https://www.bigfix.me/fixlet/details/23387

I want to run this as a policy.
In relevance I want the fixlet to look for any pc name that starts from “desktop” and change it’s computer name to for example: newpc01 and also add it to domain at the same time, and this number should change with every other pc.

Need to know what changes I need to make in this fixlet or what to put in desciption. @cjwolford helped me once. I tried a few things but it didn’t work out for me.

Please assist.

@strawgate @jgstew @JasonWalker @cjwolford

2

If anyone using this can share the code that would be great. Just need to figure out which part of this script to edit.

3

Does it have to be newpc01? what if it were the bigfix computer ID? like new841391

If every computer joins the same BigFix env, then the BigFix computer ID is always unique.

4

Normally if I was not going to work on something I’d stay silent and see whether someone else picks up the gauntlet. Since you tagged me on the post though I’ll give a but of explanation.

That’s a pretty complex ask. I’m not sure I understand the use case for it. Because it’s complex, doesn’t have a wider use case that I can see, would take a considerable amount of time, and would have security implications, I don’t think this is something I can spend time on.

Renaming client machines isn’t too bad, but you’d need to do that based on some client attribute. You’d have difficulty using an incrementing number like ‘newpc01’ and ‘newpc02’, because one client doesn’t know which number another one chose. OS Deployment handles naming computers based on their MAC address, Serial Number, Asset Tag, or IP Address, because these can all be detected at the client and may be an avenue for you to consider.

A fixlet to change a name of a Domain computer or to Join a domain will need Domain credentials. Those are security sensitive, as they could be retrieved from the client or by malicious action queries to the relays. We have a method to protect those on the server and relay, known as Secure Parameters. With Secure Parameters, the password can be uniquely encrypted and sent to each targeted endpoint. But because the encryption keys for each client need to be known when you take the action, you cannot target such an action dynamically or make it a policy - the keys for the clients are not created until they register to the Bigfix deployment.

I’d recommend instead of doing this kind of a policy, you check into using OS Deployment and Bare Metal Imaging, which can handle installing the OS, uniquely naming each machine, and performing the Domain Joins when you provision the machine.

5

This is true, you have to be very careful with this, and I’d recommend a “domain join only” account for this purpose, but even that should have it’s password rotated regularly, which would mean stopping and restarting the action.

This would also mean that anyone with access to a client or relay in bigfix would potentially be able to see this password (unless maybe it was in a site that computers only subscribed to if they are NOT on a domain? That is a clever thought)

But regardless, you are definitely opening yourself up to someone joining your domain that you didn’t authorize, because to do this in a way that would prevent that would also make it hard to have it be a policy action.

Also, what about computers that are supposed to NOT be on a domain? do you have that situation?

6

The first step is to detect what computers start with “desktop” in the name, so that would be:

computer name as lowercase starts with "desktop"

The next step is, what is your preferred method to rename the computer on the command line? there are many options. Plus, this should require a reboot to take affect, not sure if that needs to be done before joining the domain or not.

7

It can be anything, that’s fine. I just want it to be on the domain with a unique name.

8

I agree! It’s a complex ask. This is what I’m trying to achieve.

We have new surface that will get imaged in remote branch and their names will desktop-xxxxx these X’s are some random characters that image applies.
Since these surfaces will be on the network. I want to join them to domain with a unique name and that’s all.

And in the relavance I want it to grab only computer name starts with desktop which @jgstew just mentioned below which will work.

I just don’t know what to edit in that join active directory domain fixlet to make it work for me.

9

Yes, I will have a domain join only account for this. And will keep changing the password.
I dropped the idea of of running that as a policy since I understand now that it’s not an ideal situation.

Thanks for the computer relavance, that would work perfectly.

How do I put the OU, username and password and domain information in the fixlet above?

10

This seems like the ideal way to join a computer to the domain and rename it at the same time, but requires powershell 3.0 it seems: Rename computer and join to domain in one step with PowerShell - Stack Overflow

Based upon the above stackoverflow answer, it does seem like you would have to reboot to change the computer name and reboot again to join the domain, unless you use certain methods that may allow both to happen at once without rebooting inbetween.

You COULD do it, with a domain join only account with a rotating password, but you’d just have to be careful about how it is targeted in case you have computers you don’t want to join.

If you just wanted to rename computers, this would be easy.

If you just wanted to join computers to a domain, then it would be relatively easy using the existing fixlet you linked.

Doing both is harder, unless you reboot twice.

1 Like
11

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.

2 Likes
12

I created an Automatic Computer Group for helping to Identify computers that fall into these related groupings.

Automatic Computer Groups:

I would recommend adding these to your root server to help you identify the scope of the affected machines and make sure it aligns with what you expect.

Normally I wouldn’t recommend putting most bigfix content into the “master action site” but these might actually be an exception.

1 Like
13

Sorry it has been a while, but I’m now looking into implementing this. It is on my ToDo list. I hope I don’t regret saying this 3 months from now when I haven’t gotten to it.

1 Like
14

It’s only 1 month!! :slight_smile: Anything?