AD Bind computer name

[thoule]

So I'm trying to bind to AD using a policy. It's actually binding just fine, but it uses the computer's current name of "Admin's Mac Mini" to bind. I made a little shell script to use scutil and set the three names (Hostname, LocalHostName and ComputerName) to the serial number, then run the policy. However, it's still binding using the computer's previous name.

Is there a way to specify a computer name in the bind policy? Or a way to refresh the system so that it actually binds using the recently set (and currently ignored) computer name? FYI, I'm trying to use the serial number as the computerID when binding.

I know it can be done via command line using the jamf binary using the computerID parameter, but to do that, I need to specify my credentials on the command line which I can't do for security reasons.

The next step for me is going to be to set the computer name, force a reboot, then do the bind, but that seems like a big mess and I'm hoping it isn't necessary.

[Aaron]

I specify the name as part of the command - granted, I extract the name from the hostname command, but you could do the same with scutil, or something else.

The exact command I use in my script is:

dsconfigad -a `hostname | cut -f 1 -d '.'` -u username -password -domain domain.org.au -ou "OU=Macs,OU=Workstations & Servers,DC=domain,DC=org,DC=au"

I have a restricted account that I use for binding to the domain only.

[PeterClarke]

One of the things to watch out for - is that pesky 15-Character name-length limit in AD.

The name has to be unique, and no more the 15-Characters long.

So you don't want something like: "MacBook Pro 15inch - Jim Saunders Rm A403"
Since that would get "mangled down" to: "MacBook Pro 15i"
– which is not much help if you have several of them..
– So you need to start with significant unique info first…
In the above case: "Jim Saunders A4"would perhaps be the best 15-Character name ?
or perhaps better: "A403-Saunders-J"

For our LABS - we get the Name from Field-1 of the DNS Name, and it's nicely organised.
For STAFF - we have not yet got a 'method' - and it's a mess…
At the present time most of our staff don't bind to AD, but we are thinking of introducing it…
Tidying up our DNS would be one step towards achieving that.
– at present we seem to have about 10 or more different staff naming schemes in operation…
– and that is a big part of the problem.

[thoule]

@Aaron Sadly, I can't use the command line. That requires the password be entered clear text somewhere and that is not allowed in my environment. Instead, I need to use Casper's built-in AD binding function as, so they tell me, the password is kept encrypted at all times.

@PeterClarke
I'm aware of the character limit. That's why I use scutil to rename the computer to the serial number before binding. The problem is that after renaming, the Casper AD Bind function continues to use the old computer name instead of the 'just set' serial number as the computer name. I think what I need to do is run a shell script to rename the computer using scutil, then reboot the computer. THEN I can bind it...

[yan1212]

Not sure if this will be appropriate for your needs but what about wrapping the JAMF binary commands as a script to run before binding and setting the password as a variable rather than inside the command?

[thoule · Accepted solution]

@yan1212 Thanks for the suggestion, but the password is not allowed in any type of plain text on the machine.

I did find a solution, however. It seems the jamf process holds some environment variables during its run. So renaming the computer was ignored by the currently running process when it went to bind. To get around this, I created a second policy (adbinding part2), then called that with /usr/sbin/jamf policy -event adbindingpart2 via script at the end of the computer renaming. By starting a second policy after the computer renaming, it is using the correct computer name for binding.

[jarednichols]

This makes sense as a shell session (interactive or otherwise) will not see a hostname change until the next session. This is expected behavior.