Apple Macs losing AD binding

Zahid, thanks for more hints on maintaining a healthy domain binding on a Mac. Our most common problem is lack of authentication, even though the binding is still good. Reboot is the simple fix, though it seems to be a time sync issue for us. "ntpdate -q timeservername" (or domainname) to see the time drift between the client and the domain shouldn't matter with less than 5 minutes of drift for the domain account. Authentication seems to be a lot touchier, though. Updating the time "fixes" it for us right away.
-Nate

I am not sure if this will resolve your issue, but it may help to add an additional search policy for AD after binding. Open Directory Utility, click Active Directory and then click the Search Policy button. Click the plus sign and add the available directory domain. Move the newly added domain up in the Directory Domains list and click apply. Your computers will find the directory a bit faster and log in authenticating against AD.

Again, not sure if this will resolve your issue, but it may help. Adding the additional search policy doesn't seem to be a feature of the Directory Bindings function in the JSS. Good luck!

Tammi

From the list you've done everything I would normally do to try and make it as robust as possible. The only possibilities I can think of are:

- Time server related (as @nateburt mentioned) - Network connection speed (by that I mean the speed the clients connect to the network). I have seen some sites where there is a significant delay from initial boot up to the point where the Mac has an IP and can reach other devices (particularly the DC). - Computer objects being moved in AD. The Macs should be able to cope with this but I'm including it in the list just in case. - Another security setting / policy in AD throwing the Macs out (I'll leave this one open for others to comment on!) - A possible problem with the particular version of Mac OS and your AD domain, you could test 10.9.5 or 10.10.1 to see if the behaviour changes. - Finally, deep freeze could be causing an issue, again as a test you could try thawing the Mac to see how it gets on (unless this causes too many other issues, in which case the below recommendation might suit you).

If re-binding is a task you're finding yourself doing regularly, you could put in a script that gets the computer to read its own object from AD, if it can't, flag that there is an issue (possibly extension attribute and smart group membership, followed by an email to you), then automatically rejoin the domain (again emailing to confirm it has left the "broken binding" smart group). We've implemented a system like this for a few customers, the script will need to carefully crafted to avoid false positives etc but it does help to work around problems like this.

Thanks Tammi,

Davidacland, I like your suggestion of rejoining the domain automatically. I'd be be grateful if you could elaborate on this. I have created a couple of scripts that just help me when bind/unbinding and i was tempted to just put the bind script into some sort of startup script but I don't wanna be just binding unnecessarily cos as you know this will delay the user even more.

I'd save rebinding automatically for a last resort - it's better to fix the problem. As you know, there is a computer object in AD which the computer binds to. There is a password between your computer and the AD object for that binding to work which you don't see or know about. And that password is randomly changed every so often. I wonder if when you revert via Deep Freeze, you are reverting to the old password for that AD object which 'breaks' the binding. Try to avoid reverting via deep freeze and see if that fixes it. You can also ask you AD admin about not auto-changing AD passwords, but I suspect that may not be possible.

The outline script steps are:

• Read computer object AD using dscl (I would put a dscacheutil -flush cache at the start to make sure its not just reading a cached value)
• Use $? (the exit status of the last command) to determine if it was successful (a 0 should mean all is well)
• If there is an error, send the result up to an extension attribute (text field) using curl and the REST API

The other prep work would be:

• Create the extension attribute that can hold the value
• Create a smart group that looks for specific text in that extension attribute
• Create a policy that is scoped ongoing to members of that smart group (with an inventory update at the end to make sure it doesn't keep running)

You then just need to create a launchdaemon or a policy to trigger the script at a regular interval.

On the API point, you could create a script populated extension attribute and then run a full recon if there is an error. I would probably prefer to use the API as you only want the one field populated but either way would work.

Sorry I don't have an up to date script to hand otherwise I would just post that!

Here's an example of the Extension Attribute we use to determine if a Mac is properly joined to the company domain.
It will report if lookup fails, or (from 10.7 and above) if the AD keychain entry is missing, or if its on the outside of the network when it reported in. Or lastly, if everything is in order.

We pretty much have zero trust in dsconfigad -show by itself. As has been mentioned in other threads, its just reading from the local DOMAIN.plist file that gets generated at the time of binding, but won't get removed unless the Mac is disjoined from AD (normally or forcibly) so just having that file there is not a good indication of whether communication to AD is actually good. We only use it in the script to determine if the Mac thinks its joined and what the Computer Account name should be when doing a lookup later on.
Unfortunately, Casper Suite's built in AD field uses the same information as dsconfigad -show so it can be inaccurate as well. Hence why we made the EA.

#!/bin/bash

OSvers=$( sw_vers -productVersion | cut -d. -f2 )

## NOTE: Change "dc.domain.comp.org" to an internal master domain controller,
## or some other internal device for the ping command

if ping -c 2 -o dc.domain.comp.org; then
    ## Mac is on the network, continue
    if [[ $(dsconfigad -show | awk '/Active Directory Domain/{ print $NF }') == "domain.comp.org" ]]; then
        ADCompName=$(dsconfigad -show | awk '/Computer Account/{ print $NF }')
        ## Mac has correct dsconfigad info, continue
        if [[ "$OSvers" -ge "7"  ]]; then

            ## NOTE: Change the "DOMAIN" in the command below to your domain name

            security find-generic-password -l "/Active Directory/DOMAIN" | grep "Active Directory"
            if [ "$?" == "0" ]; then
                ## AD keychain file exists, continue
                ## NOTE: Change the "DOMAIN" in the command below to your domain name

                dscl "/Active Directory/DOMAIN/All Domains" read /Computers/"$ADCompName" | grep -i "$ADCompName"
                if [ "$?" == "0" ]; then
                    ## Successful lookup of computer record. AD communication is working
                    res="Yes"
                else
                    res="No - AD Lookup Failed"
                fi
            else
                res="No - AD Keychain Not Found"
            fi
        else
            if [[ "$OSvers" == "6" ]]; then
                ## OS is 10.6.x, moving on to AD lookup
                ## NOTE: Change the "DOMAIN" in the command below to your domain name

                dscl "/Active Directory/DOMAIN/All Domains" read /Computers/"$ADCompName" | grep "$ADCompName"
                if [ "$?" == "0" ]; then
                    ## Successful lookup of computer record. AD communication is working
                    res="Yes"
                else
                    res="No - AD Lookup Failed"
                fi
            fi
        fi
    else
        ## NOTE: Change the "domain.comp.org" in the command below to your fqdn
        res="No - Not Joined to domain.comp.org domain"
    fi
else
    ## Mac is not on the network or has no network connection
    echo "Not connected to company network"
    res="Remote"
fi

echo "<result>$res</result>"

You could probably use something like the above and modify it to rejoin to AD in the case of lookups failing or the keychain being missing. Just have a function to re-bind in the script that would get called in those instances. Or, use a separate policy that gets triggered on Macs that fall into a Smart Group that doesn't have a value of "Yes" for example.

As @davidacland mentioned, you want to be careful with this, as you may need to rejoin Macs to their existing records in AD, overwriting them. So just make certain it needs to be done before actually (re)binding, since if it uses the incorrect information it could clobber an existing AD computer record, causing issues for some other Mac.

dsconfigad -passinterval '0'

http://support.apple.com/en-us/HT3422

i'd put money on what @thoule said about deep freeze and the AD computer object password

Thanks everybody for your advice.

However, mm2270 could you please tell me on how to compile (it lookslike C program) the script if it indeed needs to compiled into an executable and how to attach to a launch daemon.

Thanks

Hi Zed, its a bash script, you add it directly to an extension attribute in the JSS (Settings > Computer Management > Management Framework > Extension Attributes).

Select "Script" as the input type.

Once the Macs run their next inventory update the field will be populated with the results from the script.

The only downside (although I could be wrong), is a broken AD connection wouldn't be reported for up to a week, depending on when the last inventory update ran.

Sorry davidacland, i'm being really thick here but what is JSS? (JavaScript?)where would i find this? is on the Mac? or a windows DC?

It's the JAMF Software Server, ie https://jssaddress.com:8443

I might have missed something here though, do you have Casper?

No Casper :(

@Zed2014 I would ask your AD admin what the computer object password refresh time is. I think the default is 14 days.

Find out what that delay is and perhaps turn off deep freeze for a couple days longer than that delay and see if the machines still become unbound. I'm pretty sure thats what the problem is.

I haven't used deep freeze in many many years so i can't remember how you go about freezing and unfreezing. But perhaps it is possible to schedule a script to run once a week or something that thaws the deep freeze image, unbinds and rebinds to ad, then freezes again. That should help keep the machines bound

Thanks Calumhunter. I'm an AD admin myself and yes it is set to 14 days. However, I have overode this as mentioned in my original post point number 2 (under "Now the problem")

I've turned Deepfreeze for several days no difference. What is so peculiar is the randomness i.e Mac No3 might drop off and then Mac No 14. Very strange as they were all imaged together at the same time so I'd expect consistent behaviour but it's far from consistent hence diagnosing is very difficult

Without Casper you can still use the "self-healing" approach I mentioned, just ignore the extension attribute / API bits. Instead, run the check script locally on the Mac as before on a schedule of your choosing (via a launchdaemon) if an issue is found, run another command / script to rebind.

all,

I have seen this with AD bound Mac systems 10.8.5 and up when using Deep Freeze. Faronics knows of this bug and it is something we have worked with them on resolving. Not the best AD guy but has something to do with back end AD process for updating a certificate. When frozen this update is not possible. If more info is needed I can gather my list of support tickets for additional details.

Hey @mm2270 - I realize that this post is a couple years old, but I stumbled on your extension attribute script above and have it working for our situation. Thanks. What I am trying to get a better understanding for is all of the layers you have and if a computer has to pass all of those situations to be able to change their password.

In our company we require that users change their password every 60 days. It leads to a lot of frustration when the Mac's can't change the password due to AD issues. And we have found that AD can be a challenge.

For example if AD lookup failed or the AD keychain not found comes up, does that mean they won't be able to change their password? I am not clear on what exactly is needed for a good connection to AD.

Thanks for the help!

It was suggested I share this with the community. I use this to create an extension attribute. Then a just 're-use' ongoing policies to rejoin the domain if with the scope defined by the EA. By default the machine account will update every 14 days but we increased our interval to accommodate vacations in Europe.

#!/bin/bash ADPSWD=$(/usr/bin/security find-generic-password -s "/Active Directory/ADNAME" /Library/Keychains/System.keychain 2> /dev/null | grep mdat | awk '{print substr($2, 2, length($2)-7)}') if [[ $ADPSWD -gt 0 ]]; then d1=$(date -j -f "%a %b %d %T %Z %Y" "date" "%s") d2=$(date -j -f "%Y%m%d%H%M%S" $ADPSWD %s) result=$(( (d1 - d2) / 86400 )) else result="9999" fi echo "<result>$result</result>" exit 0

Is it just our site or has anyone else noticed that AD Macs are falling off their domain more frequently? I know the built in password interval of 14 days for AD has always been the default for OSX but we've never seen computers drop AD like we have since El Cap. I don't know if it's something on our AD server that has changed or if OSX is now actually using that 14 day interval.

I know I can fix this by increasing the password interval days or disabling it all together. I'm just alarmed by the amount of computers this year in our environment dropping off AD and was wondering if I'm the only one seeing this?

Chuck

I've been at my current job for 2 years now and I can honestly say that I NEVER once had any problems with Macs joining and staying joined to our Active Directory... until the past week. In the span of a single week, I have suddenly encountered 2 (and possibly a 3rd) Macs that can no longer communicate with Active Directory.

My observations:
1) using the script above as a guide, I was able to verify that the active directory keychain item was missing from the affected computers.
2) these problems only surfaced after our Network and InfoSec teams enabled a proxy. (EDIT: and server patching)
3) The only way to get them back on the network is to force unbind them and then rejoin them. I use our JSS Active Directory utility to automatically join and insert themselves in the proper group membership.

My questions:
1) what would cause the AD keychain item to be deleted? I know for a fact they were there and properly working with AD previously.
2) why would the addition of a proxy server affect this (assuming that's the cause)?

It appears that our sudden problem with the Macs dropping off AD may be related to some server patching that occurred the day before the first reported problem. There's a handful of Windows Server updates that specifically "fix" problems with computer passwords (but ends up breaking for Macs). I still don't know exactly what it changes or what I have to do to fix it. Until I can figure that out, I have come up with a way to not only notify me of an affected computer but also have JSS fix it on its own.
First, there's the EA that @mm2270 shared with us above.
Next, I built a smart group that is based on the "No" results of the EA
Next, I built a simple script based on the command found here.
Next, I created a Policy that is scoped to the smart group I created. I set it for Ongoing so it runs at check-in and also made a custom trigger so I can run it at-will. (I might make a Self Service item for it too.) In SCRIPTS, I put the script I built with the setting to run BEFORE. Then I included our standard DIRECTORY BINDING. MAINTENANCE has Update Inventory (to remove the computer from the smart group).

So far the tests are successful and I think this will save me the hassle of trying to fix it on each affected computer before. ... at least until I can fix the underlying cause.

@AVmcclint Please keep us posted on your search. I am finding many of our machines loosing the AD Keychain item but I haven't been able to track it back to a root cause. I will look into server updates. Thank you for that bit of information.

The automated detection and repair is working flawlessly so far. At least I've got that going for me. It has detected and fixed about a dozen machines now. I'm working on getting the server team to undo the patches that relate to computer accounts, but I don't know how long that's going to take.

I should clarify that I built the smart group based on the "No - AD Keychain Not Found" results. This weeds out the AD lookup failures because that is sluggish on our WiFi even on a good day. I find Macs that report AD lookup failures usually report that at startup and will be normal within 15 minutes after login is completed so there is no need to repair those.