Woah, domain admin?
Bigger question... why is a domain admin account being used to bind/unbind machines to your domain? Create a role account that can only bind or unbind. Then, while it's not ideal, you won't have to worry so hard about the creds being in a script.
EDIT: NTLMv1 uses MD4 and NTLMv2 uses an MD5 hash. Both are unsalted. (::shudder::) Give that a go.
Sorry, I was being unclear - the script just needs credentials that have permission to bind/unbind. The account I know of that can do that happens to be a domain admin, though you're right that it might behoove us to create an additional one.
Could you provide more details about your edit? (I'm not really a sysadmin, just a helpdesk tech who needs to fix domain binding issues when they crop up - and yes, this happens often enough that I'd like to do it with a quick Casper policy if that's possible.) Are you saying that if I find out what version of AD/NTLM we're using, then encrypt the password via MD4 or MD5 as appropriate, I can just put that in the script (or in Casper as a parameter) and it'll work?
Are you saying that if I find out what version of AD/NTLM we're using, then encrypt the password via MD4 or MD5 as appropriate, I can just put that in the script (or in Casper as a parameter) and it'll work?
Hash, not encrypt. They're different things and it's important to understand that. But yes, this is pretty much what I'm saying. Since they're unsalted passwords, you can use a standard MD4 or MD5 hash of what the password is and should be able to pass that in your script. It's exactly what the Casper quickadd.pkg uses in its script. If you generate one, you'll see that there's a hashed password of the account being used to join a Mac to your JSS.
Hashes are safe to use in scripts because they're one-way functions. You can't 'unhash' it and get your password out. As an aside, unsalted hashes are attackable however. What happens instead is a dictionary attack. An attacker will run (literally) dictionary words through a hash algorithm and store the output. If an attacker is able to gain the stored hash values, if they're weak passwords they can simply look up matching hash values and then work backwards to what the original password was. This is why salting (adding randomness) is extremely important when storing passwords.
Active Directory doesn't salt their hashes (however 2012 may add it - I don't know). Microsoft's theory is that systems/users/whatever with certain access rights should be the only things with direct allowed access to the hash database (such as your Domain Admin).
Myself, I don't trust anyone, let alone Microsoft, to code a perfect security system so I'd prefer to see a system using hashed values Just In Case
.
In your case, you'll likely luck out because you don't need to know what that salt value is to generate a hashed password that you can use in your script.
You can use aes256 Encryption for this.
You'll need 3 Key things:
- Encrypted String
- Salt
- Passphrase
See this URL and how to do it: https://github.com/kc9wwh/logCollection/wiki/Using-Encrypted-Strings
Here is the script I made for Jamf.
-------------------------------------------------------------------------------------------------------------
#!/bin/bash
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
#
#
# Written by: Nick Guru
#
# Options Variables
# 4 = Username
# 5 = Encrypted String
# 6 = Salt
# 7 = Passphrase
#
#
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
## User Variables
jamfProUser="$4"
jamfProPassEnc="$5"
## System Variables
mySerial=$( system_profiler SPHardwareDataType | grep Serial | awk '{print $NF}' )
currentUser=$( stat -f%Su /dev/console )
compHostName=$( scutil --get LocalHostName )
timeStamp=$( date '+%Y-%m-%d-%H-%M-%S' )
osMajor=$(/usr/bin/sw_vers -productVersion | awk -F . '{print $1}')
osMinor=$(/usr/bin/sw_vers -productVersion | awk -F . '{print $2}')
jamfProPass=$( echo "$5" | /usr/bin/openssl enc -aes256 -d -a -A -S "$6" -k "$7" )
# Remove domain bind from computer. Runs with -force to not require a working domain connection to complete the action.
# Note that real AD credentials are not required for a force-unbind.
sudo /usr/sbin/dsconfigad -remove -username "$jamfProUser" -password "$jamfProPass" -force
exit 0
