It has been some time since my last post, so I thought, what would be better than giving Jamf Connect some love again 🙂

So let’s have a look at one specific feature built into Jamf Connect Verify: Automatically mounting FileShares!

I’m testing here with Jamf Connect Verify, but Jamf Connect Sync is actually quite similar (with some difference regarding the com.jamf.connect.sync.plist). I might do another post for Sync later, but in the mean time you can find the instructions for Kerberos and FileShares in Sync here.

As always, first things first, read the manual which you can find here.

For those who want to jump immediately to the ‘Troubleshooting” section, click here.

Next, the pre-reqs:

  • Kerberos: reading the manual you’ll immediately notice one important requirement at the very first line: “If you have configured Kerberos in Jamf Connect Verify,…”, so yes, we need to configure Kerberos in Jamf Connect Verify.
  • A file share or shared folder which you want to mount
  • Home Folders configured for your domain users
  • An on-premise Active Directory

Let’s start with the last requirement, ‘an on-premise Active Directory’… wait, we are using Jamf Connect Verify with Azure… why would I need an on-premise AD?

Well, because of Kerberos! While Jamf Connect Verify is used to keep the local password in sync with the cloud password in Azure AD, we can’t do Kerberos with Azure! Only Azure bound Windows 10 devices can, but that’s miles away from what we are doing here… managing macs!

This means that this feature will only be available for hybrid environments, where the on-premise AD is synced with Azure AD. Yes synced, not federated with ADFS… I decided to take a break from any ADFS related discussion at the moment.

With synced I mean that you linked the on-premise AD, via Azure AD Connect to Azure AD and configured either Password Hash Sync or Passthrough Authentication. Both work fine with Jamf Connect.

In this scenario, you will configure Jamf Connect to authenticate to Azure, as discussed in one of my previous posts.

Before we dive into configuring Jamf Connect for Kerberos and the FileShares, let’s quickly review the two other pre-reqs: the shared folder you want to mount, and home folders for the domain users.

Allow me to assume that you know how to configure a Shared Folder on the server and OS of your preference, so to keep the length of this post within limits, just a few gotcha’s:

  • Create an SMB file share
  • Make sure it is reachable from wherever the Mac of the enduser might need to mount it. Taking VLANS and subnets etc into account
  • Assign the right permissions for the end users

For the Home Folder however, I just want to take a quick moment to have a look at how to define those for your end users. For this, we go to our Active Directory Users and Computers, and configure the Home Folder in the properties>Profile of the user account. In my test setup, I’ve put the Home folders in the ‘Users’ folder of my Win2016 server, but this can be any location on the network of course. This ‘Users’ folder should be shared by default, but worth to check anyway.

Note: To specify a network path for the home folder, you must first create the network share and set permissions that permit the user access. You can do this with Shared Folders in Computer Management on the server computer.

With our Home folders and FileShares in place, the next step would be to configure Jamf Connect Verify. Remember, the first thing to put in place is Kerberos, so let’s start with that!

As said, Kerberos only works against the on-premise Domain Controllers, so we need to add some keys to our Jamf Connect Verify configuration profile / plist:

<key>KerberosRealm</key>
<string>TRAVELLINGTECHGUY.DEV</string>
<key>KerberosGetTicketsAutomatically</key>
<true/>

The first key is the Kerberos Realm, this is basically the domain of your Domain Controller to which you’ll be authenticating to get the tickets. The second key is self-explanatory, configuring JC Verify to automatically check for Kerberos tickets at login.

Now, this leaves us with the following Jamf Connect plist, in which I added a few optional keys to hide the Home Directory Menu (which does show up under shares anyway if that one is not set to hidden):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>OIDCProvider</key>
    <string>Azure</string>
	<key>OIDCROPGID</key>
	<string>1d884884-ABCD-0000-WXYZ-71548a60aa76</string>
	<key>OIDCChangePasswordURL</key> 
<string>https://account.activedirectory.windowsazure.com/ChangePassword.aspx</string>
	<key>KerberosGetTicketsAutomatically</key>
	<true/>
	<key>KerberosRealm</key>
	<string>TRAVELLINGTECHGUY.DEV</string>
	<key>MenuShares</key>
	<string>TTG Shares</string>
	<key>MenuHomeDirectory</key>
	<string>TTG Home</string>
	<key>HideShares</key>
	<false/>
	<key>HideHomeDirectory</key>
	<true/>
</dict>
</plist>

As you can see, there is nothing in this plist which is defining the fact that the Home Folder or any FileShares need to be mounted, and no information about the location of the shares either. That’s because we need a seperate plist for that! The com.jamf.connect.shares.plist

You can deploy this second plist via a seperate config profile, or just add it as a second ‘custom settings’ payload in the Jamf Connect Verify profile. Let’s have a look at what that ‘Shares plist’ looks like, and keep things simple.

As this plist is a little more complex than the other Jamf Connect plists, I’d really advise to start with basic things first. One share to test with, linked to a specific group is really enough to test a first deployment. You can always add more shares later.

So, what do we need?

1) the HomeMount section
2) the Shares section
3) and optionally some payload metadata

<plist version="1.0">
     <dict>
	<key>HomeMount</key>
	<dict>
		<key>Groups</key>
			<array>
				<string>Test</string>
			</array>
		<key>Mount</key>
		<true/>
		<key>Options</key>
		<array/>
	</dict>
	<key>PayloadDescription</key>
	<string>Jamf Connect</string>
	<key>PayloadDisplayName</key>
	<string>Jamf Connect - File Shares</string>
	<key>PayloadIdentifier</key>
	<string>09527DB7-AA93-4AE9-9D3D-D5EEC790C44B</string>
	<key>PayloadOrganization</key>
	<string>Jamf Connect</string>
	<key>PayloadType</key>
	<string>com.jamf.connect.shares</string>
	<key>PayloadUUID</key>
	<string>09527DB7-AA93-4AE9-9D3D-D5EEC790C44B</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
	<key>Shares</key>
	<array>
		<dict>
			<key>AutoMount</key>
			<true/>
			<key>ConnectedOnly</key>
			<true/>
			<key>Groups</key>
			<array>
				<string>Test</string>
			</array>
			<key>LocalMount</key>
			<string>/Volumes/JamfShare</string>
			<key>Name</key>
			<string>TTG Shares</string>
			<key>Options</key>
			<array/>
			<key>URL</key>
			<string>smb://10.0.1.1/JamfShare</string>
		</dict>
	</array>
	<key>Version</key>
	<string>1</string>
</dict>
</plist>

Let’s start with the HomeMount section, as this one is really straight forward. The only thing it requires is the Home folder to be configured at the AD level (see above), the Mount key set to True, and finally the Group key set to an AD Security Group to which your end user belong that need their Home folder to be mounted with JC Verify! Easy!

In my plist above I set the Group string to a Test group I’ve created in AD and added the user I’m testing Jamf Connect Verify with as a member.

Further options can be set where needed, see screenshot from the admin guide below, but as said, let’s keep things simple for a first deployment!

Next, let’s have a look at the Shares section. This needs a little bit more information, and some additional keys. The main keys are the Groups (just like the HomeMount, the group who needs this FileShare), the Name for the Share in the JC Verify Menu and the URL for the SMB mount.

Optional are the AutoMount (will automatically mount the share on JC Verify login), the ConnectedOnly (only tries to mount the Share when the mac is in reach of the domain) and a LocalMount if you want to mount the Share in an existing Local Mount Point.

Similar to the HomeMount you can also define some options as mentioned above.

That’s basically it! Deploy the plist as custom settings in a config profile, sign in to Jamf Connect Verify… and wait for the MAGIC to happen!

First thing you should see is the Jamf Connect Verify logo turning GREEN. This means you have a valid Kerberos ticket. Once the Kerberos ticket is there, you should see both the Home folder and the additional Share being Mounted (if you have the Finder settings set to show connected servers on the Desktop of course 🙂 Otherwise you’ll need to check in Finder).

Troubleshooting
  1. Maybe too obvious, but is the user signed-in to JC Verify?
  2. Did the JC Verify icon turn green?
    The icon only turns green if it got a valid Kerberos ticket. If not, troubleshoot Kerberos first! Try if you can get a Kerberos ticket Manual via the Keychain Access app. Keychain Access menu > Ticket Viewer (see screenshot below)
  3. If you got a valid Kerberos ticket, but the Share/HomeMount is still not mounting, can you mount the Share manually? Finder>Go menu>Connect to Server… SMB://IPAdressOfTheSMBServer/ShareName

    If not, troubleshoot the SMB connection. Firewalls, VLANs, Subnets, … you now all the networking stuff.
  4. If you have a Kerberos ticket and you can mount the Shares manually, there is probably something wrong with the com.jamf.connect.shares.plist (When I was testing, it did not work, I asked a copy from my colleague Mike, changed the URL/IP of the SMB Share… and guess what it worked. Not idea what was wrong, but I’m just saying, a small typo in the plist and all goes down the drain… @MIKE Thanks btw).

    Also, maybe too obvious again, but crosscheck if the config profile succesfully deployed, and if you made changes to the plists… check in the config (after saving) if the changes you made were applied… I’ve noticed that sometimes just uploading the new plist does not really update it… best practice is to remove the ‘custom settings’ payload, add it again and upload the new plist. Just to be sure.
  5. If all works fine manually, Kerberos is your friend, the share mounts manually, and the plist looks fine (copy mine and tweak the Share URL…) then I’m afraid Jamf Connect just does not like you, or it’s Monday morning and something else is wrong.
  6. Contact Jamf Support…

As promised, hereby a quick screenshot of the Ticket Viewer in Keychain Access… very handy when troubleshooting Kerberos!

Oh yeah, bonus tip, you can add multiple shares and multiple groups. Just add additional strings with different groups within the same share, and for additional shares, just add additional dictionaries within the Shares array. Something like this:

<key>Shares</key>
	<array>
		<dict>
			<key>AutoMount</key>
			<true/>
			<key>ConnectedOnly</key>
			<true/>
			<key>Groups</key>
			<array>
				<string>Test</string>
                                <string>TestGroup2</string>
			</array>
			<key>LocalMount</key>
			<string>/Volumes/JamfShare</string>
			<key>Name</key>
			<string>TTG Shares</string>
			<key>Options</key>
			<array/>
			<key>URL</key>
			<string>smb://10.0.1.1/JamfShare</string>
		</dict>
                <dict>
			<key>AutoMount</key>
			<true/>
			<key>ConnectedOnly</key>
			<true/>
			<key>Groups</key>
			<array>
				<string>TestGroup3</string>
                                <string>TestGroup4</string>
			</array>
			<key>LocalMount</key>
			<string>/Volumes/JamfShare</string>
			<key>Name</key>
			<string>TTG Shares</string>
			<key>Options</key>
			<array/>
			<key>URL</key>
			<string>smb://10.0.1.30/anotherShare</string>
		</dict>
	</array>

That’s it! As always, if you like this post hit the like button, tell your friends about it and leave a comment down below!

Brgds,
TTG

Print Friendly, PDF & Email