Skip to main content
Question

Network Limitations & VPN users

  • March 11, 2014
  • 3 replies
  • 31 views
J
Forum|alt.badge.img+13

Network Limitations, being based on the IP address as reported at last recon, have a serious limitation: if your last recon was on-site, and you run Self Service over VPN, you'll still be able to run all policies as though you were on-site. To get around this, we've written a script that looks for the virtual interfaces that our VPN clients create, and if they are absent, call a trigger passed as a variable. This does mean that you need two policies (the one that the user will see in Self Service, which runs the script, and the custom-triggered policy that the script will call).

In our case, we do assume that the policy can only be run via VPN or on-site, since we have no management point in the DMZ.

Self Service Policy
Name: Upgrade to OS X 10.9 Mavericks
Triggered by None, Ongoing
Scope: Some Smart Group
Enable for Self Service
Script: vpnPreCheck.sh, with variable 4 set to mavericksupgrade
No reboots, no reckons, etc - just call the script

Script: vpnPreCheck.sh

#!/bin/bash

# vpnPreCheck.sh - Checks to see if a client seems to be on the VPN
# Built to exit 1 if VPN is detected, or call the specified trigger: $4

# Checking ifconfig output for the known virtual interfaces
pulseConnected=`ifconfig | grep utun`
ncConnected=`ifconfig | grep jnc`

if [ "$pulseConnected" ] || [ "$ncConnected" ]; then
    # A virtual interface is detected; we're on VPN
    /Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType hud -windowPosition ur -icon "/System/Library/CoreServices/Problem Reporter.app/Contents/Resources/ProblemReporter.icns" -heading 'VPN Connection Detected' -description 'This policy may not be run from the VPN. Please try again when you are on-site.' > /dev/null 2>&1 &
    exit 1
else
    # We're on-site; proceed to call the passed trigger
    echo "No Remote Access detected."
    jamf policy -trigger $4
    exit 0
fi

Manually-triggered Policy
Name: Triggered Mavericks Upgrade (naming things is hard)
Triggered by Other: mavericksupgrade, Ongoing
Scope: All (since we expect this to only ever be manually triggered) Packages: Our Mavericks upgrade package (via createOSXinstallerpkg) and our recon-and-delete launchdaemon
Reboot: Immediately, to Current, No-bless

So the first policy runs the script, and the script triggers the policy, so that we can be sure that a VPN user can't run the upgrade. HTH, use at your own risk, test extensively, YMMV, etc.

    3 replies

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • March 11, 2014

    The Mac's IP should/does update in its JSS record when just checking in, not only at recon time. Couldn't you create and deploy something that would trigger a check in, perhaps with jamf log whenever the /Library/Preferences/SystemConfiguration directory is updated? What I'm getting at is a LaunchDaemon that uses that as a WatchPath and, when it changes, runs a simple script to see if the JSS is available, and if so, do a sudo jamf log to get the updated IP in place.
    Alternatively, if using JSS version 9, this kind of trigger is already available in the product. You might be able to deploy it as an offline policy.
    The updated IP should land the Mac into a different Network Segment, and therefore (possibly) avoid this issue?

    I'm thinking out loud a bit here, and wondering if you already tried all the above and it didn't work?

    J
    Forum|alt.badge.img+13
    • JPDyson
    • Author
    • Valued Contributor
    • March 12, 2014

    We're still on v8 for now; plans are in place to go to 9, but there are a couple of open dependencies.

    Thanks for the clarification as to when the IP is updated; in our testing, we were probably moving too quickly to wait for a log to naturally occur, but a launchdaemon could solve that.

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • March 12, 2014

    Just a little thing to be aware of that we recently discovered. In older versions of the jamf binary, the jamf log command used to return a proper exit status. If it was successful in updating its check in time and IP to the JSS, it would return exit status 0, and if it couldn't, it returned status 1.

    Somewhere along the line in the 8 series this seems to have changed. (Haven't looked to see if this is also true in version 9) It now will always report 0, whether it was successful or not. Even if the Mac is completely off the network, it returns status 0. Very strange. We reported this to our account manager and he is saying that the traffic isn't two way, so the binary doesn't actually get anything back on whether the log command was actually successful;. It seems as far as the jamf binary is concerned, if the command ran at all it was successful. :P This doesn't make any sense to me, but that seems to be how it works now.

    For this reason if you do decide to script something called by a LaunchDaemon, I suggest first doing a sudo jamf checkJSSConnection -retry 1 (or 2 if you want to give it a little more time). That command will correctly return an exit status that reflects whether it was successful or not, so you can check its exit status and if 0, move on to the jamf log command.

    I just did some quick verification on these a moment ago and the jamf log command does update the IP immediately as well as the Last Contact Time in the computer record, so you should be able to use that to move the Mac into the correct Network Segment.

    Terms & ConditionsCookie settingsAccessibility statement