OD Binding at Imaging not working since 8.64 update

[tuinte]

Dear JAMFNation:

I updated yesterday to 8.64 from 8.6 and OD binding has ceased working at imaging time (as well as with Casper Remote). OD is 10.6.8 OS X Server.

I've recreated the JSS binding entry and am trying a configuration with only our base 10.8.3 image and the binding.

From jamf.log:

Tue Apr 23 15:45:55 caspertest jamf[1392]:   Securely binding to od.company.com
Tue Apr 23 15:45:55 caspertest jamf[1392]:  Error: The binding was not successful:
Please enter network user password: 
dsconfigldap verbose mode
Using suggested computer ID <caspertest>
Options selected by user:
Force authenticated (un)binding option selected
Add server option selected
Server name provided as <od.company.com>
LDAP Configuration name provided as <od.company.com>
Computer ID provided as <caspertest>
Network username provided as <diradmin>
Local username determined to be <root>
Adding new node to search policies

I've also tried with a base 10.7.5 image so I don't think it's anything in the OS image.

Unsecure (insecure?) bind works, but we need a secure bind. Trying to apply the binding via Casper Remote:

Opening SSH Connection to 192.168.x.x...
Authenticating...
Successfully authenticated.
Verifying Computer's Identity...
The MAC Address has been verified.
Checking Operating System Version...
Running Mac OS X 10.8.3 (12D78)
Verifying /usr/sbin/jamf...
/usr/sbin/jamf is current (8.64)
Verifying /usr/sbin/jamfvnc...
/usr/sbin/jamfvnc does not exist.
Verifying /Library/Preferences/com.jamfsoftware.jamf.plist...
Preparing Policy...
Executing Policy 2013-04-23 at 3:45 PM | hostcomputername | 1 Computer...
caspertest:~ localadmin$ -bash: localadminpassword: command not found
caspertest:~ localadmin$
Finished.

This seemed a bit strange to me. Where it says localadminpassword, it listed the client computer's local admin's password in plain text (password is not the same as directory admin's). Is this a lead of some sort? Why is it issuing the local admin's password as a command?

Would really appreciate some help as I'm considering quitting my job and living in a forest.

Michael

[tuinte]

I shall give an update!

Obviously I tried binding manually. A secure bind fails with an error for incorrect credentials (though they are correct). An unsecure bind works OK, and after this I can then perform a secure bind and it works. Unbinding and rebinding gives me the same thing: straight secure bind does not work; unsecure bind, then secure bind, works.

So then I removed Casper entirely. I straight up Carbon Copy Cloned the same Base OS DMG from CasperShare (literally pulled it out of the Distribution Point), and imaging that way, binding works as expected (secure bind and all).

It looks like Casper Imaging is doing something to the OS as it images that creates my secure binding issue. Does that sound close to right?

Thanks for any help.

Michael

[tuinte]

Update for future generations:

I did a file comparison and noticed a difference between a Casper
Imaging-imaged machine and a Carbon Copy-imaged one.

Comparing the two copies of /Library/System
Configuration/preferences.plist:

From Carbon Copy:

<key>System</key> <dict> <key>Network</key> <dict> <key>ComputerName</key> <string>computername</string> <key>ComputerNameEncoding</key> <integer>0</integer> </dict> </dict>

From Casper Imaging:

<key>System</key> <dict> <key>Network</key> <dict> <key>ComputerName</key> <string>computername</string> <key>ComputerNameEncoding</key> <integer>134217984</integer> <key>HostName</key>
<string>computername</string>
</dict>
</dict>

(If you take a look at the file, this is the area near the bottom. There's the key "System" and within that the two keys "Network" and another "System". This is from the second "System".)

I'm not sure what the ComputerNameEncoding integer does, but manually editing the file - setting the ComputerNameEncoding integer to 0 and removing the HostName key and computer name string lines, then rebooting - resolves the issue. The computer binds normally after that.

The original OS image, as created by Composer, contains the same data the CCC image does (no surprise). Casper Imaging seems to add a HostName and change the integer to 134217984 (where does this number come from?).

I'm kind of surprised it doesn't go the other way (ie, the computer WITHOUT the hostname would fail at binding), but there it is.

Does this mean anything to anybody? I'm writing a small script for imaging to remove the Hostname line and set the integer to 0, which I anticipate will be workable, but I'd still like to know what's happening (there are a few rather large threads on here about computer's not being named at imaging, but they seem to be about the issue of using an image from one model of machine and applying to another model, and the same preferences.plist file then not getting a local hostname).

Thanks for any help!

Michael

[tuinte]

Updated to 8.7. No change.

[rcorbin]

I don't know why but binding via Casper always seems to be an issue for us. We are currently running 9.32 and can't really bind via Casper but you can bind manually just fine.