Skip to main content

Hi,



So we're having an issue with our AD bound Macs (using Apple's built in AD connector) where after an hour they lose their ability to authenticate to AD.



This generally shows itself if the user is logged in and the screen lock comes on they will not be able to log back in.



Or if the computer is booted up, but no one logs in, after an hour the red dot will appear at the login screen.



Only solution seems to be rebooting the machine.



This is what we captured in the opendirectoryd log when set to debug mode right at the hour mark when it fails:
(sudo log stream --level debug --process opendirectoryd >> ~/Desktop/odir.log)



2018-08-08 11:39:56.562194-0500 0x4983 Debug 0x0 77 opendirectoryd: (SystemConfiguration) [com.apple.SystemConfiguration.SCNetworkReachability] [0x7faffacb4720] unscheduled

2018-08-08 11:39:56.562310-0500 0x4983 Debug 0x0 77 opendirectoryd: (SystemConfiguration) [com.apple.SystemConfiguration.SCNetworkReachability] [0x7faffacb4720] release

2018-08-08 11:39:56.562396-0500 0x49ca Error 0x0 77 opendirectoryd: (ldap) received ldap error -1 - disconnecting connection

2018-08-08 11:39:56.562436-0500 0x49ca Default 0x0 77 opendirectoryd: disconnect module connection

2018-08-08 11:40:17.569285-0500 0x4b1d Default 0x0 77 opendirectoryd: Client: <private>, UID: 0, EUID: 0, GID: 0, EGID: 0

2018-08-08 11:40:17.569353-0500 0x4b1d Debug 0x0 77 opendirectoryd: submitting request to internal pipeline



2018-08-08 11:40:17.631000-0500 0x4b1f Debug 0x0 77 opendirectoryd: (ldap) packet encryption is allowed

2018-08-08 11:40:17.631050-0500 0x4b1f Default 0x0 77 opendirectoryd: (ldap) connected to server

2018-08-08 11:40:17.631112-0500 0x4b1f Default 0x0 77 opendirectoryd: (ldap) attempting GSSAPI authentication @ 0

2018-08-08 11:40:17.631163-0500 0x4b1f Debug 0x0 77 opendirectoryd: (Security) [com.apple.securityd.secpref] New DLDbListCFPref 0x700004dbe448 for domain 1

2018-08-08 11:40:17.631213-0500 0x4b1f Debug 0x0 77 opendirectoryd: (Security) [com.apple.securityd.secpref] force=true prefsPath=/Library/Preferences/com.apple.security.plist

2018-08-08 11:40:17.631337-0500 0x4b1f Debug 0x0 77 opendirectoryd: (Security) [com.apple.securityd.secpref] after LoginDLDbIdentifier(), we think the login keychain is /Library/Keychains/System.keychain

2018-08-08 11:40:17.631394-0500 0x4b1f Debug 0x0 77 opendirectoryd: (Security) [com.apple.securityd.secpref] now we think the default keychain is: /Library/Keychains/System.keychain (actual: /Library/Keychains/System.keychain)



2018-08-08 11:40:17.641294-0500 0x4b1f Debug 0x0 77 opendirectoryd: (Heimdal) [com.apple.Heimdal.libkrb5] krb5_get_credentials_with_flags: AD.SOMEUNIVERSITY.EDU wc: 0.000141

2018-08-08 11:40:17.641514-0500 0x4b1f Debug 0x0 77 opendirectoryd: (Heimdal) [com.apple.Heimdal.libkrb5] krb5_get_credentials_with_flags: AD.SOMEUNIVERSITY.EDU wc: 0.000147

2018-08-08 11:40:17.643222-0500 0x4b1f Default 0x0 77 opendirectoryd: (libsasl2.2.dylib) GSSAPI Error: The context has expire (Success)

2018-08-08 11:40:17.643324-0500 0x4b1f Default 0x0 77 opendirectoryd: (ldap) failed authentication error: -2

2018-08-08 11:40:17.643481-0500 0x4b1f Default 0x0 77 opendirectoryd: disconnect module connection

2018-08-08 11:40:17.664701-0500 0x4b1f Default 0x0 77 opendirectoryd: (ldap) failed authentication error: -2

2018-08-08 11:40:17.664828-0500 0x4b1f Default 0x0 77 opendirectoryd: disconnect module connection

2018-08-08 11:40:17.664903-0500 0x4b20 Default 0x0 77 opendirectoryd: disconnect module connection

2018-08-08 11:40:17.664948-0500 0x4b1f Debug 0x0 77 opendirectoryd: (SystemConfiguration) [com.apple.SystemConfiguration.SCNetworkReachability] [0x7faffafc3f40] create w/address pair <SCNetworkReachability 0x7faffafc3f40 [0x7fffbcf6ada0]> {local address = 10.10.10.5, remote address = 10.50.50.10}

2018-08-08 11:40:17.664996-0500 0x4b1f Debug 0x0 77 opendirectoryd: (SystemConfiguration) [com.apple.SystemConfiguration.SCNetworkReachability] [0x7faffafc3f40] scheduled

2018-08-08 11:40:17.665088-0500 0x4b5d Default 0x0 77 opendirectoryd: ODNodeCreateWithNameAndOptions failed with error 'Connection failed' (2100)

2018-08-08 11:40:17.665167-0500 0x4aef Default 0x0 77 opendirectoryd: (search) search node offline - <private>

2018-08-08 11:40:17.665204-0500 0x4b1f Debug 0x0 77 opendirectoryd: (SystemConfiguration) [com.apple.SystemConfiguration.SCNetworkReachability] [0x7faffafc3f40] unscheduled

2018-08-08 11:40:17.665379-0500 0x4aef Info 0x0 77 opendirectoryd: ODQueryCreateWithNode completed


The primary error lines that start showing up are:

2018-08-08 11:40:17.643222-0500 0x4b1f Default 0x0 77 opendirectoryd: (libsasl2.2.dylib) GSSAPI Error: The context has expire (Success)


and 



2018-08-08 11:40:17.643324-0500 0x4b1f Default 0x0 77 opendirectoryd: (ldap) failed authentication error: -2


Our Macs had been connecting to our AD for over a decade across many OS versions without issue but suddenly this process started to fail last month. Our current workaround has been to enable mobile account since it can cache the credentials.



Some of our lab computers use Thursby's client and do not seem to suffer the same disconnection issue. Though recently while looking at the logs we realize that this may not be the case in that they are simply recovering from the error.



Could there be something like DDNS that could be causing problems? We run DDNS on Infoblox and AD in parallel. Our networking group tells us that DHCP is set to have a 24 lease and so clients are generally expected to renew every 12 hours.



As for the AD connector we have tried all the possible variations from the command line using dsconfigad (passinterval changes, packet encrypt/signing require, allow, disable, etc) but the behavior continues. Though if someone has a particular configuration they want us to try we are game.

I deploy AD binding as a policy using the Directory Binding feature in jamf. We have it create mobile accounts on login.
We then run a script afterwards to configure a few more AD settings. 



#!/bin/sh

dsconfigad -preferred {{domain_controller_url}}



# set password cache interval to 0 days so AD password changes are immediately recognized

dsconfigad -passinterval 0 



# disable localhome and sharepoint

dsconfigad -localhome disable

dsconfigad -sharepoint disable

I completely agree with the above post its something everyone should do, i da as a matter of course

@McLeanSchool The -passinterval specifies the number of days that the computer will change it's own computer account AD password, not related to users at all. Setting this to 0 might post a very slight security risk.



From man dsconfigad:



-passinterval value

              Set how often the computer trust account password should be changed (default 14).

We have found the answer after standing up a test domain controller and also from hints from an older JAMF thread:
https://www.jamf.com/jamf-nation/discussions/11658/insane-ad-authentication-issue-help#responseChild127729



Basically the reason the AD bound Macs were falling over (authentication wise) at 60 minutes after having booted up and connected to AD was because of an unknown change that had happened with the default Domain GPO policy on our Domain Controllers.



Specifically it was the "Maximum lifetime for service ticket" policy setting
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-service-ticket



Somehow it had set itself for 60 minutes versus what it likely had before which would have been the MS recommended default of 600 minutes.



When we set the "Maximum lifetime for service ticket" policy setting to 600 minutes then the Macs are able to keep their connection happily at all times.



Thanks though to everyone who provided feedback!

Terms & ConditionsCookie settings