Apple Macs losing AD binding

Hello

Ok, so I am going to write out everything i have done for a set of 30 Laptops (20 Airs and 10 2010 MBPs). These devices are all running Sierra 10.12.6. This has NOT resolved the issue but so far it has slowed it down considerably.
All of our Payloads are managed by Jamf Pro.

Learning Common Macs setup
- 10.12.6
- Deepfreeze
- Machine Authentication - 802.1x
- Wifi Payload - Auto Join SSID, WPA2 Enterprise, PEAP, Use as Directory Authentication, Use as a Login Windows Configuration
- All other options are in one Payload.
- Radius Cert
- Root Cert
- Alertus
- Sophos

Steps Taken to resolve the AD Drop Off Issue
I did this to each of the 30 Laptops. Took many days especially the machines with no SSD's.
- AD: Disjoin and Rejoin, 'dsconfigad -passinterval 0', Mobile Accounts - ON, Set Preferred domain server, unchecked Allow Authentication from any domain in the forest
- Ran any updates
- Turned off Auto Check for updates
- Removed any other Network Connections and set the Wifi to be primary adaptor.
- Added New WiFi Payload - Auto Join SSID, WPA2 Enterprise, PEAP, Use as Directory Authentication, Use as a Login Windows Configuration with 2 Certs (Radius and Root-CA cert) (via JSS)
- Other Payloads - Restrictions, Login window, Parental controls.
- Opened Keychain and changed 'When using this certificate' from 'Default' to 'Always Trust'

This issue is also occurring on our Ethernet Connected Labs (all running 10.12.6) the issue is like a wildfire. Over the weekend pretty much all of our Mac Pro's fell of the Domain. Staff/Faculty devices are also affected but with Mobile accounts and the script running via a Smart Group we seldom see these machines in the office. Only when they need to add a Network Printer as the Printer list does not show up.

Cheers,
A.

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.