Skip to main content

Hello!

We are having some issues using the screen sharing functionality in Jamf Remote when users are not on the company network, but connected with the global protect VPN agent. On our Windows devices, we aren't seeing any issues (we use Goverlan) to connect to users outside of our network. Before going to Jamf, we were using Apple Remote Desktop, which didn't have issues with this.

Now with Jamf, we are unable to start up screensharing with users that connect to our network through Global Protect. Our Palo Alto consultant has looked into this, and according to him, the computers aren't registering in DNS properly. He claims this is an Apple issue, but we didn't see this issue when using ARD.

Has anyone encountered this issue? If so, what is the way to solve this?

The consultant gave me the script below to try. When running this however, I get the message that it's a read-only file system. I'm running the script on Catalina, so I assume this is because the OS now runs in a read-only system volume. Any help would be gréatly appreciated, as I am out of ideas how to fix this.

This is the script the consultant gave me:

#!/bin/sh

# en0 = ethernet - en1 = airport - choose the right interface !
IPADDR=`/sbin/ifconfig en0 | grep 'inet ' | awk '{print $2}'`
HOSTNAME=`hostname -f`

# Optionally set the name server (if not present, it uses system default).
# echo server "${DNSSERVER}" > $TMPDIR/nsupdate

# Change > to >> if name server set.
echo update delete "${HOSTNAME}" A > $TMPDIR/nsupdate
echo update add "${HOSTNAME}" 86400 A "${IPADDR}" >> $TMPDIR/nsupdate
echo show >> $TMPDIR/nsupdate
echo send >> $TMPDIR/nsupdate

nsupdate $TMPDIR/nsupdate

Thanks!
Valérie

Nobody has run into this, I'm guessing? Sadly, still stuck on the same thing.

Presumably $TMPDIR is set to something that you can't write to, if you try opening a shall and running

echo $TMPDIR

what do you get, can you write a file there?

I'm presuming this $TMPDIR variable is set via OSX (it's certainly set for me on 10.14 in /var/folders/qv/<longrandomstring>/T, which I didn't do). It would seem kind of rubbish for Apple to have this set for you to somewhere you can't write to in Catalina, but who knows...

If getting to the bottom of why this doesn't work seems like more trouble than it's worth perhaps you and if you can determine a writeable destination for temp files in 10.15 you could perhaps set the variable in your script by defining

$NEWTMPDIR="/path/to/somwhere/writeable/"

Then replacing occurrences of $TMPDIR with $NEWTMPDIR

As an aside, I found your post searching JAMFnation for some syntax on using nsupdate, to try and poke some recalcitrant AD bound Macs into doing Dynamic DNS updates against our AD, which they should be doing automatically.
In the process I've been forced to recall various bits of OSX kerberos authentication which I thought I'd share in case you get your script running and find that you bounce off your AD DNS servers.

For what it's worth the approach to automating the nsupdate side of things works fine, my issue was that our AD DNS servers only allow authenticated updates. AD bound computers can use their computer account in AD to authenticate and update their own records.
To do the same thing you need to use the kerberos credentials the computer has stashed in keytab in /etc/krb5.keytab.
You also need to use the -g flag on nsupdate to make it do AD authentication.

If you were to need to make this work on an AD with only authenticated DNS updates allowed, and AD bound Macs (which should be doing this already)

your script would work pretty much the same way but you would

replace

HOSTNAME=`hostname -f`

with

HOSTNAME=`scutil --get ComputerName`

Add a line

adcomputernm="$HOSTNAME$"

And replace

nsupdate $TMPDIR/nsupdate

with 

kinit -k -t /etc/krb5.keytab $adcomputernm nsupdate -g $TMPDIR/nsupdate
Terms & ConditionsCookie settingsAccessibility statement