Macs dropping connection to Centrify Direct Control - how to monitor

[corbinmharris]

We are binding our Macs to AD with Centrify Direct Control 5.11
Sometimes we have issues when the Macs are no longer connected to DC. This then prevents the user from updating their password when it is time

Anyone have an Extension Attribute or another way to report if the Mac is no longer connected to DC?

Thanks! Corbin

[JPDyson]

We have some Centrify EA's that basically pull info from adinfo. So, for example, if you wanted to know if a Mac was in "Connected" mode, you grep out that line and toss it back.

#!/bin/sh

mode=`adinfo | grep "CentrifyDC mode" | awk '{print $3}'`

if [ "$mode" == "connected" ]; then
    echo "<result>Connected</result>"
elif [ "$mode" == "disconnected" ]; then
    echo "<result>Disconnected</result>"
else
    echo "<result>NA</result>"
fi

(That final "else" case is just for the few Macs we have which are not bound with Centrify)

[mm2270]

@corbin3ci][/url][/url][/url - its been years now since I used Centrify Direct Control, but if my memory serves me, isn't it just facilitating the bind to Active Directory. as in, it uses its own plug-in to bind rather than the built in Apple AD plug-in?
If so, you could probably write something that would do a simple lookup against AD. For example, have the Mac check for its own computer record in AD as an Extension Attribute. I believe the command line Centrify DC tools can help with pulling the computer's AD name from itself to use for the lookup. I don't think you can use dsconfigad since that's related to Apple's plug-in (I could be wrong on that though)
If the lookup is successful, it should indicate its talking correctly with AD. If it fails, either the connection is broken or the Mac is out of range of your AD domain controllers. That last item is a possibility with mobile machines, so you may need to account for that in your EA.

FWIW, we have something that verifies our AD binds as part of an EA, but we're using Apple's AD plug-in. The general principal is the same as what I outlined above, and it really helps us with verification. Unfortunately we found we couldn't trust what dsconfigad -show was telling us, since it seems to read from a locally stored plist file. The connection could still be fubar, but dsconfigad will happily report that its "joined" to AD, oblivious to the reality. Casper Suite's built in Active Directory Status also relies on dsconfigad -show, so its no more accurate. So we had to take additional measures to verify the connection with a custom script.

Edit: Or, you can just ignore everything I wrote and use what JPDyson posted, since he's using it and would know far better than I how to detect the Mac's connection. :)

[JPDyson]

*snickers*

@mm2270 You're correct; a simple dsconfigad -show is not going to return anything; adinfo is one of the binaries that would replace that functionality for use with CDC.

[alexjdale]

What happens if you try to "id" an AD username with Centrify? That's a test I use on Macs with the native plugin to see if they can resolve network accounts, and if not, that tells me there is a bind issue. That would be easy to script for an extension attribute.

What the system thinks is not relevant, even with dsconfigad the system may think it's bound to AD but that doesn't mean the bind is working. Running a test action is ideal, in my opinion.

[BLau]

Hi Corbin,

Mr Dyson has the right idea in that you can check the current connected status of the Mac by checking the Centrify agent's Connected status flag.

You can actually reference it directly by using "adinfo -m" thus eliminating the need to use awk and grepping out the result.

Here is what I use when I need to monitor the agent's Connected status in the background:

#!/bin/sh
#
# Interval in seconds between each adclient-connect-check for the network
CHECK_INTERVAL=5

osascript -e "
repeat
    try 
        set connectedState to do shell script "adinfo -m"

        if connectedState is "connected" then
            exit repeat
        else
            delay $CHECK_INTERVAL
        end if
    on error
        delay $CHECK_INTERVAL
    end try

end repeat"

It's a bit of a hodgepodge between shell and Applescript, but it's unnoticeable in the background, doesn't hold up any processes and incurs no extra network traffic as it's merely checking an internal flag in the agent itself.

Hope that helps,
Brian

P.S. It looks like you have a current account with us at Centrify too - Get in touch and we'll see if we can pin down those disconnection issues in the first place and help you find the root cause.