Where in the world are the logs for OpenDirectory
I can see /Library/Logs/PasswordService has some logs in it referring to user auth, but I set od to debug level logs and those files haven't changed in 2 days now.
Yes, this is frustrating. Especially for those of us who remember the days of .LogDebugAtStartOnce.
The best I can recommend is the following. Start by setting OD into debug logging:
sudo odutil set log debug
Then use the log command to stream a filtered result of just your debug logs from the OD subsystem:
sudo log stream --predicate '(messageType == debug) and (subsystem == "com.apple.opendirectoryd")'
You can output this to a file or just copy and paste from Terminal after capturing for a while. This has worked for me so I stopped researching the creation of a persistent file.
Hope this helps
Reid Bundonis
Carbon Technologies, LLC
Apple Consultants Network member
Yes, this is frustrating. Especially for those of us who remember the days of .LogDebugAtStartOnce.
The best I can recommend is the following. Start by setting OD into debug logging:
sudo odutil set log debug
Then use the log command to stream a filtered result of just your debug logs from the OD subsystem:
sudo log stream --predicate '(messageType == debug) and (subsystem == "com.apple.opendirectoryd")'
You can output this to a file or just copy and paste from Terminal after capturing for a while. This has worked for me so I stopped researching the creation of a persistent file.
Hope this helps
Reid Bundonis
Carbon Technologies, LLC
Apple Consultants Network member
Ok, new syntax for Mojave. Try this:
1: Enable debug logging using odutil command
2: Now use the --debug switch in the log command instead of the filter:
sudo log stream --debug --predicate 'subsystem == "com.apple.opendirectoryd"'
That is now producing debug output for OD related actions. I tested by modifying a user.
With luck this is the secret sauce that get's you the answer you are looking for.
(However, I believe change password has been broken for some time now. If I recall, there were issues with that in High Sierra also, including once enabling the policy it effected the diradmin account).
See if this helps with the debugging.
Looking at line 190 of `client.log`
```
opendirectoryd: (AppleODClientLDAP) [com.apple.opendirectoryd:default] Unable to connect to LDAP server - ldap_start_tls_s failed with error 'serv er connection failed' (-11) SSLHandshake() failed: misc. bad certificate (-9825)
```
Seems like its all surrounding the ssl handshake to the ldap server (OD server). I'm double checking to make sure I have all the correct certs installed on my test client
Definitely helpful, didn't know about the log stream command, however I'm not getting any log output from opendirectoryd, even after changin the odutil log levels, and trying on both client/server.
Finding the logs is just a means to finding a solution to an issue I've been struggling with on OD for a few weeks now. For some weird reason, I can't set a user's password to be changed at next login. There are no password complexity requirements setup, it just refuses to enable login for a user who requires a password change, and at the login window no matter how many passwords I try, it refuses it. I can't seem to trigger a debug log by failed password change attempts, so I have no leads.
Heeeeyyyyy now I'm seeing some logs! I attached two logs with ~300 lines of output that I get when attempting a fresh login on an account with the reset password bug (sadly the console colors didn't persist). One for the client (2017 macbook pro) and one for the server. I'm going through these myself now, I'll come back if I find anything noteable!
I got this to work (10.4.3 server and 10.4.3 client), both with an encrypted bind and an unencrypted bind.
1: Built OD Master with a fixed IP address, FQDN that resolves in DNS, and with a valid SSL certificate
2: Bound a 10.14 client to the server using Directory Utility and checking the box "Encrypt using SSL"
3: Created an account, daffyduck, with a password daffy on the server
4: Set login window to user name and password and entered initial user name and password
5: Was prompted to change password
6: Set password to 123456 and committed the change
7: Change accepted and user allowed to login for first time.
When I initially tried this, I was on user name at the login window and I needed to click the account, then dismiss the change password dialog since I did not pre-auth with the original password. This allowed me to enter the original password which then presented the change password dialog. I was able to change the password but the change password box would not disappear. Pressing cancel, I was then able to login with the new password. (I cheated on this first test and used createmobileaccount command to prestage the account.
Yeah looks like it just doesn't like my macos server generated OD cert. I don't think there's a way to generate a new one and tie it to my existing OD setup. I tried disable the required cert auth in all the /etc/openldap configs, but it didn't seem to take.
Think this just boils down to a software bug with no foreseeable workarounds
In my case the test user is an existing user who has logged in on the hardware once before, and a mobile account has been created. I've just manually changed the user's password in Server 5.7.1 and checked the "change password at next login" checkbox, and they're unable to change it. Not sure if this mirrors your setup or not.
I also went back and checked off "ssl" under the ldap settings in directory utility, as it wasn't configured to use ssl before. Still won't let me change the password.
I was testing slightly different. I had set the global password policy to "be reset on first user login." However, I did as you are doing. I selected an existing user, right clicked, selected Change Password, reset the password and then checked the "require password change at next login" box.
Going back to the client, I was able to enter the user name and old password (to pre-auth) which prompted me to change password. The change password was accepted and as login continued I was notified of a keychain password mismatch.
So this appears to work. How did you bind the workstation to the server? Did you use Directory Utility or just System Preferences? Perhaps you have an unauthenticated bind and that is what is preventing the change. Just a thought.
Argh... You are correct. No longer working on Mojave. Just did it on High Sierra and it works. Let me see what I can sort out here. This is becoming a constantly moving target.
Open directory log files Server 5.7.1