Documentation

Other

Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

dscl query fails upon return to LAN

I have been using @bentoms Applescript to mount network shares with mixed results for about two years. I have had intermittent issues with shares not mounting, but I haven't had the time to do any in-depth diagnosis. Due to some ongoing organizational changes I have retired that script and I have written a bash script that performs a similar function but with different logic and lots more logging.

The logging has directed me to what I believe is the reason why I have been having intermittent issues with the share mounting: when a device has been off our LAN and has returned to the LAN without being shut down, it appears unable to completely browse AD using dscl. This occurs despite having a valid kerberos ticket and being able to access network resources without manual authentication. Since the script cannot query AD, it does not perform as expected.

The script tries to read Active Directory/mycompany/mycompany.org. On an affected device, if I open a terminal window and enter dscl in interactive mode, I can browse using cd and ls, but I can only browse to the Active Directory/mycompany/ level. I can see All Domains with an ls command, but I can't progress past this point. I receive this error:

I suspected that this had to do with the account losing some component of their domain privileges during the off-LAN period, however, if I log in as a non-domain user I am able to browse using dscl.

My options at this point are to:a.) test for a null result from the dscl lookup and notify the user that they must reboot in order to mount network sharesb.) figure out why AD is not browseable in that situation and take some action to remediate

I would rather not force users to restart in these situations. Has anyone else experienced this? Any ideas how to get past this issue? FWIW I am also unable to auth into AD while on an affected device.

This is a really common issue unfortunately. The "/Active Directory/XXXXXX/" part is present on all bound Macs, regardless whether they are on the LAN or not. If you have a look at a Mac with its ethernet cable unplugged and wifi switched off you'll see that you can get that far. As soon as you try to go any deeper it requires an actual connection to a domain controller.

The most common cause is opendirectoryd as its triggers to check for connectivity to the DC can be a little erratic. If the eDSUnknownNodeName error occurs, I would probably add into your script steps to:

I've seen this issue as well. I have an extension attribute that identifies machines that are "No longer bound to AD". When a machine is in this state, they cannot change their password via System Preferences / Account (the change password button is greyed out); however, they are still able to perform multiple functions on the domain.

After a time on the wire, the machine will return itself "to the fold", and it will be working normally again. Your description seems to match what I'm seeing as well, though I've been unable to determine a root cause. I agree with you, they have a valid Kerberos ticket, so that's not it...it seems to be more related to the computer account itself, but I'm speculating (though I know that leaving the domain, and then rebinding will always correct the problem).

I am going to try David's opendirectoryd recycle though and see if that fixes it.

@ bentoms - the issue that I had with your script failing wasn't due to any errors within the script. We are a smaller organization and have an increasing number of users who need regular access to shares outside of those typically assigned to their AD group. Conversely, we also have some AD groups that map shares that all members may not have access to. In the first circumstance, the user is required to manually map any non-standard drives. In the second, the Applescript errors out when it attempts to mount a share that the user does not have access to. I realize that this is an AD issue and not a problem with your script, but I don't manage AD, so I have to play the hand I am dealt.

I use a brute force attempt with this script - it attempts to mount all group shares on our network. I will be the first to admit that it is not an elegant solution, however it has been working (albeit somewhat slowly).

The issue in my original post doesn't appear top be with the Kerberos ticket, but instead is some wrinkle with the binding. I tried the approach suggested by @davidacland , but it did not resolve this issue. I instead elected to notify the user that network resources would be unavailable until a reboot occurs, as this resolves the issue every time.