Skip to main content

Hello, thanks for looking at this in advance. Recently, I've had a bunch of OS X 10.8.5 computers not able to log anyone in using their Active Directory Accounts. Bind was bad. So, I do what I normally do 99% of the time, unbind the machine from command line, remove the computer record from AD, re-bind via command line. 99% of the time I'm successfully bound, issue an "id whatever_name" and returns what I expect.

This week I've had 5 iMac Intel (Early 2009) running OS X 10.8.5 where I cannot rebind to AD. When I try to via command line i get this error:

dsconfigad: The daemon encountered an error processing request. (10002)

I check AD and the record was created but when I issue a dsconfigad -show on the machine, it returns nothing.

So, I go to Directory Utility and try to bind that way. It acts like it's going to work until the very end and it says:

Unable to store password

I've fixed disk permissions, tried binding a bunch of different ways, and the only thing I can do to get it re-bound is to re-image the machine. Re-imaging isn't a big issue since I can get it done, software all installed in less than 30 minutes but I want to know why this is happening and if there is a fix besides re-imaging

If anyone has encountered this issue or could provide some insight, it would be greatly appreciated.

Thank you in advance

I sometimes see "The daemon encountered an error processing request" messages as well, but these are 99,99% of the time temp isolated issues.

If you want to know why, "odutil set log debug" is your friend (together with Wireshark), then look into /var/log/opendirectoryd.log and system.log files.

I highly recommend to disable this AD logging immediately after you get your error message (with odutil set log default), otherwise you will spend days and not hours, to read the generated logs :-).

Thanks @Olivier I have a machine I kept around that has this error so I will try this with that machine.

@Chuey We are having a similiar issue with daemon error (10002) - Could you elaborate if you had some other solutions besides reimage?

chasing this down myself, the issue is intermittent and sometimes gets resolved with a restart. I'm seeing this on 10.11.6 as well. On bind attempt, a computer record is created in AD, but the AD password is not stored in the system keychain. sudo systemkeychain -tv is showing a valid keychain unlock as well, so not sure what the issue is yet. Maybe it's trying to write the AD password to the JAMF.keychain and failing?

I've had this a couple of times - every time it's been caused by having a faulty /etc/krb5.conf

Terms & ConditionsCookie settingsAccessibility statement