Ever had the issue with some users (that are mostly working remote) come in to the office, trying to login with his/hers computer and can’t logon?
Many have a policy and a script that is being used to remove computers from the domain that haven’t authenticated for a while (let’s say 60 days)
So what happens ?
1: The user has trouble logging in (because the computer account is deleted)
2: The user contacts helpdesk
3: The helpdesk most likely needs to get a hold of the computer and manually join the computer to the domain again.
4: Or needs someone else who has access join the computer to domain to do it.
So this is a bit time consuming, so what can we do to automate this process?
There are several approaches, the recipe I am going to write now is far from a security best practice but it is just to show you how you can do it. In addition, there are loads of different ways to achieve this.
And by looking at this recipe you will see that I have manually entered the computername it is not fetched from another activity.
The recipe I am writing now has some prerequisites that needs to be meet in order for it to work.
1: Local user on the client-computer that you can use to run the script
2: Firewall opened on the client-computer so we can access the $admin shares.
3: The computer has its IP config in place
4: And the script is able to reach the computer using hostname.
Now my simple runbook looks like this.
What it does is.
1: Create a folder C:tempscript on the client-computer
2: Copy over my PowerShell scripts from a network share.
3: Runs a PowerShell script from that folder (Which joins the domain, waits 10 second then does a restart)
Now in order to have this automated you should place an “Initialize data” activity where you can enter the computer name which is then sent through the workflow.
1: Create Folder activity (Needs to run with a local user account (Under details you define where the folder should be created, for instance c:tempscript)
2: Copy File(Copies the scripts from a network share and places it into the newly created folder)
3: Run Program (Which is based upon psexec)
Which will run the script that was copied over to the folder.
In addition, remember to run as context of local user under Security pane.
Now the script is pretty simple all it does it stores some variables such as domain, username and password.
Then runs a restart-command after.
The script is
$domain = “domain.domain”
$password = “password” | ConvertTo-SecureString –asPlainText –Force
$username = “$domainadministrator”
$credential = New-Object System.Management.Automation.PScredential($username,$password)
Add-Computer –Domainname $domain –Credential $credential
You should apply a shutdown /r /t 10 in order for the runbook to have time to reply back to Orchestrator
Now what could we do to enhance this runbook ?
1: An Activity to delete the folder with files on the client computer (because it contains a password and should not stay on the computer)
2: If we have a local user and password for each computer we should get the runbook go get the unique username and password from a text file.
3: Generate a new random password for the domain join account each time it is run, then update the script.
4: Get information from AD (I’m pretty sure that this information pops up on the event logs on the DC’s and can become automated process from there)
5: Or from SCOM ACS module, when SCOM creates an alert which shows computers with these
6: Give the user a notification that the process is happening and should save his/her current work.
7: Automate the process to a self-service portal (but this on the other hand would grant users to run this task on any computer)
So in the end we might have something like this.
I’m going to do give deeper into this in the next couple of posts.