AD Binding-Failing During Imaging Only

johnnasset
Contributor

Using the built-in AD binding in the JSS, imaged machines are failing to bind. Once restarted, we can use the same credentials to bind successfully through Directory Utility. Here is what we get in the console log:

Mon Dec 10 15:12:14 cr-imac102874 jamf[239]: Binding cr-imac102874 to hsd1.org...
Mon Dec 10 15:12:27 cr-imac102874 jamf[239]: An error occurred binding to Active Directory: dsconfigad: The plugin encountered an error processing request. (10001). (Attempt 1)
Mon Dec 10 15:12:38 cr-imac102874 jamf[239]: An error occurred binding to Active Directory: dsconfigad: The plugin encountered an error processing request. (10001). (Attempt 2)
Mon Dec 10 15:12:49 cr-imac102874 jamf[239]: An error occurred binding to Active Directory: dsconfigad: The plugin encountered an error processing request. (10001). (Attempt 3)
Mon Dec 10 15:12:59 cr-imac102874 jamf[239]: An error occurred binding to Active Directory: dsconfigad: The plugin encountered an error processing request. (10001). (Attempt 4)
Mon Dec 10 15:13:10 cr-imac102874 jamf[239]: An error occurred binding to Active Directory: dsconfigad: The plugin encountered an error processing request. (10001). (Attempt 5)
Mon Dec 10 15:13:10 cr-imac102874 jamf[239]: Error: Giving up on Active Directory binding after 5 attempts.

12 REPLIES 12

vobizzy
New Contributor III

i had the same issue about 6 months ago,

I deleted the binding from casper admin and recreated it.

hkim
Contributor II

Occasionally I se the same thing and it's maddening. What are others doing to make sure binding works before it's handed over to a user? Policy via smartgroup?

jhalvorson
Valued Contributor

I use a first boot script to bind to AD after imaging. Kudos to rtrouton and his scripts at https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/first_boot

On my to-do list is to add a check for network connectivity within the script prior to binding. If it can't get a ping response from our internal server then quit and use jamfhelper to notify the tech to resolve the connection and try again. I haven't finished that part of the script. I believe it would fix the issue we see with devices that require USB Ethernet adapters that fail to bind to AD after imaging.

hkim
Contributor II

Color me annoyed that I even have to resort to doing this, why even bother having a built in directory binding. *sigh*

hkim
Contributor II

I can someone confirm that this happens in my scenario when USB Ethernet Adapters are used to image. Which is going to be a problem since built in Ethernet is going the way of the Dodo it seems.

lisacherie
Contributor II

Was seeing this too.

Bind via a script set to "at reboot"

Add "sleep 60" to the beginning of the script. Seems to be a delay before the USB ethernet adaptors become active, so binding attempts before the computer is on the network and fails.

nkalister
Valued Contributor

what version of the JSS are you guys running?

CasperSally
Valued Contributor II

We're 8.64, and I haven't seen this. We bind via post image script (which sets date/time before binding attempts), then calls a manual trigger to use the binding in JSS. We also have a sleep 20 built into it prior to bind.

hkim
Contributor II

This is on 8.63 but I believe this isn't fixed in 8.71 from my conversations with JAMF Support, the bug happens with USB ethernet adapters and using the built in AD binding without manually calling it via script due to exactly this, it's not getting network in time when the binding is attempted / binding is interrupted and incomplete, just plain weird with weird settings because USB ethernet adapters aren't ready for the bind.

Yes there are work arounds using a script to call on the binding policy, but honestly, shouldn't it "Just Work" if you add the binding profile to Casper Imaging?

CasperSally
Valued Contributor II

Semantics to me. The binding functionality natively working is enough for me. I prefer to call it manually, actually, so I know exactly when it's happening (after I set date/time, but before our Network Access Control package is installed).

I guess JAMF could build a delay into their binding process, but I'd prefer to adjust it as we need it. I don't need a 60 second delay, I only need a 20 second one. Someone else may need longer for some reason.

hkim
Contributor II

This is starting to go Off Topic, but for my 2 cents worth.

From my relatively brief time dealing with JAMF, I've been incredibly impressed with everyone I've worked with. I can't say that about most other vendors. They've been responsive and very willing to hear feedback and ideas and I appreciate that very much. In this particular case, JAMF has responded, and it's duly noted by development under as Defect ID:D-003025. It be nice if the whole list of acknowledged defects were opened to the client base but I can understand why they'd want to keep that closed.

That being said, I don't think as a customer base we should just let things like this slide because there's a work around. A work around is just that, it's not fixing a bug.

nkalister
Valued Contributor

weird, I've never had this problem, and we've bound probably 250 Airs to AD using a binding in the JSS while connected using USB ethernet adapters. I do run a script to configure proxy settings during imaging that may be preventing the issue from affecting me. Basically, we create a location with proxy settings in addition to the standard 'automatic' location that every mac ships with. The script creates the location with the -populate switch, which creates a service for every hardware port present . . . .which includes the USB adapter. Try using networksetup to force population of your NICs before imaging gets to the point where it wants to bind.

Also, in my opinion, the way OS X deals with removable NICs/locations/system-level 802.1x profiles is just a hair shy of completely broken. I really hope apple overhauls this whole area of OS X soon since their hardware designs are forcing us more and more into using removable NICs.