Skip to main content

I've spent the past 2.5 days reading just about every AD Binding post in these boards, but haven't seen this particular variation. Running Casper 9.24, but issue has been going on for several versions of Casper 9.x. AD binding via JSS has worked flawlessly for us for years prior to Casper 9.x, going back to version 7.3.

SUMMARY: AD Bind fails for the same reason ("Password Not Entered") via Casper Imaging (post-image jamf bind in First Run script) or via Casper Remote, but I can ALWAYS manually bind successfully on the client machine using the Directory Utility GUI. Client machines are running either 10.6.8, 10.8.5, 10.9.1 or 10.9.2.

Inspecting the jamf bind declaration in the FirstRun script, I see all of the bind parameters entered correctly (same as I use when manually updating on a client machine), with the following exception: the -password is provided as a hash. I assume this is a bug fix from earlier versions of Casper, which showed the password in clear text in the generated First Run script.

Based on the jamf.log entries, it would appear that the password hash is not be decrypted properly, or is simply being ignored. Note that the error is not that the "password is invalid"; rather, the log states that the "password was not entered".

Is this a bug?? Looks like it to me ....

BTW - we use an AD administrative user/pw that is strictly for binding to AD, and the pw does not expire.

All this being said, I haven't tried any custom scripting as a workaround, as I'm not strong on the whole scripting thing. But, if I have to, I'll figure it out. Can somebody point me in the right direction?

Thanks in advance.

Jeff Elliott
Hempfield School District

Hi Jeff,

Thanks for reaching out, and I am sorry to learn we’re having issues getting machines to bind like we’d expect.

I did a quick bit of digging and found that we do have an open defect that lines up with the behavior that you’re seeing.

D-006417, for reference.

Our Development team is aware of this issue and are currently working on getting it taken care of, so hopefully we’ll see it get taken care of soon!

The quick and dirty workarounds we have are:

1.) Bind to AD manually.

2.) Create a script to deploy:

dsconfigad -f -a (computer name) -domain (domain) -u (user name) -p (password)

If you haven’t already, I’d recommend reaching out to your Technical Account Manager so we can get a case started and get it documented and attached to our open defect for tracking purposes.

Please let us know if you have any additional questions.

Thanks!

Amanda Wulff
JAMF Software Support

Not sure if this is still relevant, but just got this error message also. Tried to bind manually on the device and it failed as well. It looks like issue may be within the AD plug-in on that client or maybe in the computer record in AD. I haven't gotten to dig any further, but wanted to throw this out there for now.

Giving this a bump. Just started running into the same issue here since upgrading to 9.32.

@joshbuddy

D-006417, the defect I'd mentioned further up in this thread, looks like it's still open, so we'll be seeing this error on 10.5 and 10.6 range computers.

It looks like the defect has a disposition of Planned for Release, so we should hopefully see a fix for it soon.

The workarounds haven't changed, and are detailed in my post further up in the thread.

Thanks!

Amanda Wulff
JAMF Software Support

Hey Amanda,

Sorry to be a pain but I'm seeing the same issue on 10.6.8 clients with a JSS of 9.4 so it looks like the defect is still there?

Thanks
Darren

Hi Wondering if there is any progress on this. I am still having the same issue on my 10.6.8 Mac's and Casper 9.81 running on Yosemite.

Thanks
Andy

Terms & ConditionsCookie settingsAccessibility statement