AD Computer reName Script

[cr4sh0ver]

The previous System Admin used a script to rename our laptops in AD, JAMF, and the local machine, which worked until a month or so back. I found the script we currently use in this thread answered by "luke_reagor" However, now, only part of the script works to rename in JAMF and the local machines, but, makes no changes in AD.

Microsoft and Apple have been releasing more and more updates related to security and encryption and my thought is that the new updates have broken that script somehow. Has anybody seen or heard about this issue? I did notice that if I manually unbind/rebind to AD the computer name gets updated, but, that won't work in a 500+ employee environment. Any input will be greatly appreciated and if there are new ways to rename bound computers to AD, input your $0.02 cents here.

[AJPinto]

Apples direction has been very clear, Apple does not want you domain joining devices and has not wanted Macs on domains for some 10 years at this point. Apple nor Microsoft are developing their products with AD+Mac workflows in mind.

We still have a few domain bound devices. I use a script to change their hostnames to match our naming standards before domain binding them. In the past I had a policy that would "fix" the domain connection (remove and rejoin in a script) when I needed to update the AD object.

[cr4sh0ver]

When I reviewed the script there is a part that, as AJPinto mentions, Unbinds/Rebinds to AD. That seems to be the part that is no longer working. Does anyone have a workaround to make it work again via script?

The script uses "jamf policy -id 143" - has that been broken by JAMF on the latest update to JAMF Pro 10.45 or has the ID# changed?

[mm2270]

No-one here would be able to tell you the ID of a policy in your Jamf server that's being called in the script. It's going to be whatever the ID is for the policy you're trying to call, which is unique for every environment. You will have to figure out what it is, or determine if that policy was removed from the Jamf server perhaps, which, if it was, would certainly explain why it stopped working.

If you can find it, open the policy in Jamf and look in the URL field in your browser. The Jamf ID will be toward the end, something like ..id=163&o=r

In my example, the ID is 163

[cr4sh0ver]

My thought was that Policy 143 was provided by JAMF to Bind/UnBind from AD since I don't see it when following instructions by mm2270, does anyone have options on what else can be done to rename bound/unbound laptops to AD?

[AJPinto]

Nope :). JAMF does not provide us any prebuild policies. For my environment Policy 143 is a 404 page as that one is long gone. All policies were built by you guys, and would be maintained by you guys. You could screen shot your policy and payloads, and paste any scripts you use to this post. We can try to help.

This script below is the last one I used to remove a domain bind, I have no idea if it still works. I always salt passwords for obvious reason. You will need a local admin account. Once the domain bind is broken, you could just rejoin the domain with policy and a directory bindings payload.

#!/bin/bash


#*------------------------ STRING DECRYPTION ------------------------*#

function DecryptString() {
	echo "${1}" | /usr/bin/openssl enc -aes256 -d -a -A -S "${2}" -k "${3}"
}

Pass=""
Salt=""
DecryptString=$(DecryptString "$5" "$Salt" "$Pass") 


adminUser="$4"
adminPass="$DecryptString"

osvers=$(sw_vers -productVersion)
echo "Search Domains"
check4AD= /usr/bin/dscl localhost -list .

## check the admin password
adminCheck=$(/usr/bin/dscl /Local/Default -authonly "$adminUser" "$adminPass")
if [[ -z "$adminCheck" ]] ; then
	echo "Admin password is verified"
else
	echo "Admin Password not working"
	exit 2
fi



######################
# Script Body
######################

dsconfigad -remove -force -u "$adminUser" -p "$adminPass"

The best option is to stop domain binding. We all know how our organizations are, and some just want to keep beating the dead horse until the maggots explode out of it. In those dead horse cases it would be best to set your hostname before you domain bind so you don't need to change anything. Rebinding also creates orphaned AD objects as there is no guarantee that the new object will automatically connect to an existing object. Just be well aware, macOS domain binding is on life support at best and apple really wants to unplug it. Personally I think it only still works because of the unix side of macOS.

[cr4sh0ver]

We just want to make this work and keep it as long as possible since it will require for us to make local users instead of authenticating with AD. Password consistency since most of our users manage Microsoft and Apple devices (500+) and multiple passwords and password management is not their forte.

The Script implemented by the previous SysAdmin is the same one (no changes made) that "luke_reager" posted here: link

For reference here is all of it: (not sure if anything will get cut due to being the full script)

#!/bin/bash
clear

# FYI, the END) and END has to be the first thing on the line, no tabs or spaces before it.

# if not running from the jss, make this sudo=sudo, otherwise leave it sudo=
sudo=sudo


oldCompNames="ComputerName: $(scutil --get ComputerName)\n"
oldCompNames=$oldCompNames"HostName: $(scutil --get HostName)\n"
oldCompNames=$oldCompNames"LocalHostName: $(scutil --get LocalHostName)"

for (( ; ; )) #only using loop to exit early on invalid entries.
do

#APPLESCRIPT TEXT
dialogText="Enter the new Computer Name. \nOld ones were... \n$oldCompNames\n"
printf "$dialogText"
#APPLESCRIPT PROMPT
newCompName=$(/usr/bin/osascript<<END
tell application "System Events"
activate
set the answer to text returned of (display dialog "$dialogText" default answer "" buttons {"Continue"})
end tell
END)

if [ ! "$newCompName" ]; then
#APPLESCRIPT TEXT
dialogText="!!! The new Computer Name is required. Try Again. !!!\n"
printf "$dialogText"
#APPLESCRIPT PROMPT
/usr/bin/osascript<<END
tell application "System Events"
activate
display dialog "$dialogText" buttons {"Continue"}
end tell
END
else

#do the work if passed all the error checks

#APPLESCRIPT TEXT
dialogText="Thank you. Click continue and wait while I perform the actions...\n\n"
printf "$dialogText"
#APPLESCRIPT PROMPT
/usr/bin/osascript<<END
tell application "System Events"
activate
display dialog "$dialogText" buttons {"Continue"}
end tell
END

#rename mac
printf "Setting mac name to $newCompName...\n"
newCompName="$(echo $newCompName | tr '[a-z]' '[A-Z]')" #making uppercase
$sudo scutil --set ComputerName "$newCompName"
$sudo scutil --set HostName "$newCompName"
$sudo scutil --set LocalHostName "$newCompName"
printf "\n"

#unbind/rebind AD
printf "Unbinding/Rebinding mac to AD...\n"
$sudo jamf policy -id 143 # our policy that unbinds and rebinds to AD

# THIS IS THE UNBIND PART OF POLICY 143. THE BIND IS DIRECTLY IN THE POLICY ###########
# #sees if already on domain. prevents error if already off domain.
# isDomain=$(/usr/sbin/dsconfigad -show | grep '= domain'| awk '{print $4}')
# if [ "$isDomain" == "domain" ]; then
# echo "On domain."
# echo "Unbinding the computer from Active Directory..."
# dsconfigad -remove -force -username "$username" -password "$password"
# else
# echo "Not on domain."
# fi
###########################################################################################


#updating jamf
printf "Updating JAMF...\n"
$sudo jamf recon

printf "\n"
break #get out of the loop
fi

done

#APPLESCRIPT TEXT
dialogText="Finished. Goodbye.\n"
printf "$dialogText"
#APPLESCRIPT PROMPT
/usr/bin/osascript<<END
tell application "System Events"
activate
display dialog "$dialogText" buttons {"Continue"}
end tell
END

[mm2270 · Accepted solution]

@cr4sh0ver Have you looked at the policies in your Jamf Pro server to see if you can locate the "143" id policy it's trying to call? You can pull up an existing policy, and copy the full URL you see in the browser, paste that into a new tab and then change the ID shown toward the end of the address like I mentioned and hit Enter. It may load. Perhaps its under a policy name that you aren't expecting.

If it doesn't load, then it was removed from your Jamf server by someone. In that case, you might have to recreate it. Your script has some information about what's happening in that policy in all those commented out lines, so it at least shows you some details of how to rebuild it if that's what you decide to do.

Also, just to mention, in terms of keeping Mac local accounts in sync with AD, I strongly encourage you to look at using the Apple SSO Kerberos plug-in. It can help your Mac users keep their local account and their AD account in password sync, and will alert them to when their password is coming up for expiration, as well as allowing them an easy way to change their AD password and Mac password in one operation directly from the Mac. If you use FileVault encryption it has the added bonus of updating the Mac's FV2 password so that doesn't get out of whack, which is ridiculously easy to do.

You really should check it out. It makes using local only accounts on the Mac in an AD environment significantly easier to deal with. We do this, though we still currently bind to AD, but for a different legacy purpose that I'm hoping we can move away from in the near future.

[cr4sh0ver]

@mm2270 I checked our script over the weekend as well as the log for the policy. I noticed the log mentioned no changes since more than a year ago. What this meant is that for some miracle the script was actually finding the computer name in AD and renaming it properly when the reName script was run. This script was meant to be run locally to change the computer name as well as in JAMF Pro but NOT AD. In summary, I was chasing my tail since it had worked for all that time until it broke following some Microsoft security updates that ran in March and April on ALL our DCs. I will mark your answer as the Accepted solution since you mentioned some other options to follow in the future for keeping computers in sync with AD. Kind regards.