Tales of SMB

In late 2016 we started moving our many many network shares from CLARiiON (SMB2) to Isilon (SMB3). I quickly started getting interesting reports from some users on shares that had moved to Isilon about “files and folders disappearing”.  This didn’t appear to be affecting all users that had shares moved to Isilon, nor was it affecting older clients (10.9 negotiating SMB2). Typically this would occur with shares that had nested directories. I was able to replicate this behavior by writing 1000 empty directories nested 2 deep. E.x. access //testshare/test1 and back out to //testshare  and random directories are now “missing”.

1000.jpg

777.png

Un-mounting and remounting the share would typically resolve the issue for a short period of time.

Working with Apple and some very courteous end users it was determined that there is a directory caching bug in 10.11 and 10.12 wherein macOS ignores an enumeration currently in play. The issue becomes more prominent when connecting to shares with large numbers of file/directories. We tested disabling directory caching by modifying /etc/nsmb.conf as follows.

[default]
dir_cache_max_cnt=0

This did resolve the issue with Finder enumerating items in Isilon SMB3 shares but created a new problem. When connecting to the DNS name of the Isilon share it presents a single ip address, but in our Isilon configuration Isilon round robins IP addresses. macOS fails to verify the share is already mounted in this scenario and keeps remounting the same share every time a new IP address is presented to the client.

dir caching disabled.png

In testing with some of our users affected by the enumeration bug they felt that this was even more disruptive than the “disappearing items” bug. We reported and discussed this issue with Apple and they validated this was also a bug on their end. Back to the drawing board.

We tested and validated that forcing SMB1 resolves this issue, since SMB1 does not have this concept of directory caching. Again I tested forced SMB1 connections with a sample of affected users. Success! While cifs performance isn’t great they appreciated being able to functionally use and trust their GUI save dialog boxes again.

I had this idea that we didn’t want to force SMB1 for all clients when the enumeration issue only seemed to affect a subset of the population (and doesn’t affect clients connecting to shares still on CLARiiON storage. I set out to create a self service policy to allow affected users to force SMB1 if they were having the Finder enumeration issue as follows.

  1. Create nsmb.conf to force SMB1
  2. Create installer package for nsmb.conf
  3. Create Extension Attribute to check nsmb.conf for forced status
  4. Create Jamf Pro policy for Self Service.

The config for forcing SMB1 on 10.11 and later with nsmb.conf is as follows

[default]
protocol_vers_map=1

I created the nsmb.conf file in BBEdit but any standard text editor should work fine.

Using Composer (or your preferred method for creating a package) create a package to place the nsmb.conf file in /etc with root:wheel 744 permissions. Upload the .pkg to your distribution point.

composer.jpg

Here is a quick and dirty Extension Attribute to check for the SMB1 forced value in nsmb.conf

#!/bin/sh

#Reports if 10.11+ client has SMB1 forced

if grep “protocol_vers_map=1″ /etc/nsmb.conf; then
SMB1_forced=”Yes”
else
SMB1_forced=”No”
fi
echo “<result>$SMB1_forced</result>”

To make the Self Service policy key a smart group off the value being returned “No”

smart group.jpg

 

Create a policy in Jamf Pro using the aforementioned smart group as the scope target, leaving the trigger as Self Service, the Execution Frequency ongoing, and install the package we just created. I added some boilerplate text for the description to encourage folks to not use this unless they were experiencing the enumeration issue.

Only use this tool if you are experiencing issues with files and directories “disappearing” while connected to SMB shares. You will need to un-mount and re-mount any shares for this to take effect.

fix finder.jpg

Now you have a Self Service policy that will fix Finder enumeration issues between macOS and Isilon hosted SMB shares.

Here is a quick look at that in our self service portal.

 

self service 2.png

self service.png

You can validate the change is enforced with `smbutil statshares -a`

e.x. Connecting to Isilon hosted share before SMB1 enforcement.

statshares.png

e.x. Connecting to Isilon hosted share after SMB1 enforcement.

stat shares smb1.png

 

 

I have verified with Apple that both of these of these bugs are on the macOS side and need to be fixed by Apple, however they are regarded as low priority and it is not currently expected that either bug will be fixed in macOS Sierra. If you or your organization are currently experiencing one or both of these issues I encourage you to file radar or enterprise cases with Apple to get upward pressure on the prioritization of these bugs.

 

 

Tales of SMB

Packaging and Deploying the McAfee EPO Agent with Casper Suite

Organizations using McAfee tools, specifically ePO, in their environment may run into trouble or questions deploying the agent that communicates with the ePO server. I have written up a process for packaging and deploying the agent with Casper Suite. This process could be easily modified for other deployment systems or packaging tools (such as Whitebox Packages).

1.) Copy the install.sh file from the ePO server repository. For ePO 4 this is located at C:\Program Files\McAfee\ePolicy Orchestrator\DB\Software\Current\EPOAGENT3700MACX\Install\0409

2.) Copy the install.sh file to a temporary location. I placed it in /tmp/mAgent_install.

3.) Open composer and drag the install.sh file (currently at /tmp/mAgent_install) into the Composer sidebar.

3

4.) Lets go ahead and rename that package from install.sh to something more descriptive like McAfee Agent 4.8.0.1938

4

5.) So now you have a package named Mcafee Agent 4.8.0.1938 that will copy install.sh to /tmp/mAgent_install.

5-2

6.) We need to trigger that script to install the agent. Lets go ahead and add a postinstall script to the package.

5

7.) The postinstall script is an easy one-liner based off the install.sh installation flags -i for install  or -u for upgrade.

#!/bin/sh
## postinstall

# Install McAfee Agent 4.0 w/patch 3
/tmp/mAgent_install/install.sh -i

exit 0 ## Success

exit 1 ## Failure

6

8.) With the install.sh file and postinstall script in place you can now generate a .pkg.

7

9.) Congratulations, you have a package that will install your environment specific ePO agent for OS X. You can drop this into Casper Suite the same way you would any other package. Once the agent is in place you can use ePO or standalone packages to deploy other McAfee software such as Endpoint Protection for Mac.

8

Packaging and Deploying the McAfee EPO Agent with Casper Suite

Adding Filevault 2 Unlock Users

I recently had a request for automating the process of adding unlock users for FileVault 2. We have some areas that have shared use / checkout portable computers and they frequently have to add unlock users for these systems. Unfortunately the CLI tools require to be fed a FV2 unlock user, which in our Casper environment we do not enable the management account for FV2 unlock as it would be presented at the EFI pre-boot interface. Additionally mobile users are not automatically enabled as FV2 unlock users like local users. So it makes adding mobile unlock users a largely manual process in our environment. The persons that deal with the day to day administration of these units has administrative credentials on the systems, this process makes the assumption the person(s) adding unlock users will have administrative credentials.

Since our environment doesn’t let us easily automate this process I at least wanted to lower the surface pain for those individuals needing to add unlock users. We have been making an effort to point users to Self Service for as many functions as possible. I jiggered up a Self Service tool that at least saves them a couple clicks and is in line with our “check Self Service first” message.

First here is the script that opens the Filevault 2 Preference Pane. It’s not very robust but it does what it needs to. It is an applescript embedded in a bash script for easy execution by the JAMF tools.


#!/bin/bash

/usr/bin/osascript <<-EOF
tell application "System Preferences"
set the current pane to pane id "com.apple.preference.Security"
get the name of every anchor of pane id "com.apple.preference.Security"
reveal anchor "FDE" of pane id "com.apple.preference.Security"
end tell

display dialog "Click the lock, authenticate with admin credentials, then click the Enable Users... button."

tell application "System Preferences"
activate
end tell
EOF

exit 0

I created a policy for self service and attached the script.

addadditionalfilevaultunlockusers

addadditionalfilevaultunlockusers2

Now a user needing to add additional unlock users can go into self service, the location they have become accustomed to finding tools and software provided by IT to add additional unlock users.

addadditionalfilevaultunlockusersbutton

addadditionalfilevaultunlockusersbutton2

After clicking the button they are presented with simple instructions on how to complete their task

statustextfilevault2

And off to the FileVault 2 preference pane they go.

Enable users

This process is specific to our needs, and our desire to keep a consistent Self Service message. If anyone else out there has been trying to tackle the “how do we add more unlock users” conundrum, hopefully this can be of some assistance.

Adding Filevault 2 Unlock Users