macOS 2018-006 security patch and AFP auto-mount

[erik_bille]

Dear fellow mac admins,

Over the last couple of days we've seen a sad (but probably sound) development in AFP auto-mounting volumes via script.

macOS security patch 2018-006 has broken most of our nice little auto-mounting scripts for customers, throwing pre-populated login-box rather than mounting the file share and volume.

Prerequisites for this to work has been that the users AFP-credentials has been present in the keychain, which in turn allowed for

#!/bin/sh
open afp://server-fqdn/share

to be run by a script (with some error handling and checking beforehand).

This patch is applied all the way down to macOS 10.12 at least, and the way we're about to circumnavigate it is with by building, signing and TCCing (verb?) a wee .app.

Testing done so far with outcome:

macOS 10.14.1 (18B75):
open afp://server-fqdn/share - without keychain item:
prompted for login.
Arrives at 'Select the volume' window regardless of specified absolute path

open afp://server-fqdn/share - with keychain item:
not prompted for login.
Arives at right volume

macOS 10.12.6 (16G1710) (This is 10.12.6. with 2018-006 applied):
open afp://server-fqdn/share - without keychain item:
prompted for login
Arrives at 'Select the volume' window regardless of specified absolute path

open afp://server-fqdn/share - with keychain item:
prompted for login. Details pre-filled
Arrives at 'Select the volume' window regardless of specified absolute path

macOS 10.14.2 (18C54):
open afp://server-fqdn/share - without keychain item:
prompted for login
Arrives at 'Select the volume' window regardless of specified absolute path

open afp://server-fqdn/share - with keychain item:
prompted for login. Details pre-filled
Arrives at 'Select the volume' window regardless of specified absolute path

Any similar experiences, comments, cooler workarounds than ours?
Happy for any inspiration/feedback.

Thanks!

[jordan_boden]

Further to this, we have also began experiencing the same issue with smb shares that are added to the users dock via network locations, this seems to affect all mapped network drives across all protocols. It also seems like the system is no longer recognising specifying a specific folder and instead just maps you to the root of the server.

[cizdziem]

I am also experiencing this issue with SMB shares. We have been using .inetloc shortcuts to SMB shares that were added to users' desktops. Previously, users could double-click a shortcut, click Connect, and the share would open right up.

Following the installation of Sierra Security Update 2018-006, High Sierra Security Update 2018-003, and Mojave 10.14.2, when users click these shortcuts, they are presented with a window asking them to provide their username and password. The username is pre-populated, and it seems they don't need to enter a password; they can simply click Connect. Then, similar to what @jordan.boden stated, the user is asked which Share they'd like to connect to.

I just noticed that this same behavior occurs with the network home shortcut in the users' Dock, which led me to find this thread.

Sorry I do not have any workarounds for this, but I wanted to note that I was also experiencing this issue in case other admins were looking for info. An Applecare technician has confirmed he's seeing the same behavior and is "opening a discussion with product engineering."

[nickbatchelor]

We are seeing this too. 10.13.6 with the update we have these problems. Without the update previously deployed scripts to mount SMB shares work as expected.

[cizdziem]

My Applecare support rep states that this was a deliberate change to prevent nefarious actors from tricking end users into mounting shares using links on websites. He said the prompt will appear before the client attempts to connect to the server, giving the end user a chance to cancel. He also stated that this is going to be the behavior, for the foreseeable future, until a more elegant solution can be found.

I find this explanation a bit odd, because prior to the Security Updates/10.14.2, when a user clicked on a link to mount a share, they were shown a dialog box asking if they want to Connect or Cancel. So the current version just appears to be a worse way of asking for the user’s consent, by prompting them for a password unnecessarily (my testing shows that you can leave the password field blank, click Connect and still be connected to the share without entering the password). And now, the absolute specified path isn't respected, and users are asked to select which volume they want to access. Hmmm...

[tnielsen]

I do not have nice things to say.

[janselmi3953]

Not to mention, if the volume is already mounted, the volume they want to go to will be grayed out since it is already mounted. This happens on our end, not sure about everyone else.

Sure, it's on the desktop and they can get to it that way, but it's creating an extra step for some not so tech savy users. I second what cizdziem is saying, while it is not respecting the absolute path. When mounting the volume, it will bring you to the root level of the share; forcing users to scroll through hundreds of shares they don't have permissions to to find theirs. Even though the path displayed to users should mount their specific share. No password is needed just like what was said in the above post.

[jordan_boden]

Does anybody know if Authenticated Network Mounts are affected by this? I've had trouble with these in general since high sierra where they would not map through JAMF, just wondered if a) anybody else had this working in High Sierra + and b) whether they are affected by the same issues outlined above.

Whats frustrating about this is that this could have easily been a non-issue with some MDM framework from Apple, something like a trusted network locations payload that can allow shares to operate in their previous state, but instead the changes have been made without any consideration to the education and enterprise environments.

Even if this is an 'intended solution' we are still unable to add network locations directly to a network share as it only maps to the root of the server, if this is intentional and not a bug then I cant see any reason why this has been done.

[deploy2020]

Hello All,

We are seeing this on 10.13.6 clients with Security Update 2018-003 (10.13.6).

In our specific case we use AppleScript to tell the Finder to "open location" and then specify the server mount path. After applying the update the users are prompted to connect and enter their password (if not in the keychain) or prompted to connect with the password pre-filled, if it is in the keychain, however in both cases the next window is 'Select the volume' regardless of specified share path.

The behaviour is similar to that described in this article: https://support.apple.com/en-us/HT207112 but we already have the /Library/Preferences/com.apple.NetworkAuthorization AllowUnknownServers -bool YES key set.

Interestingly pasting the full mount path, with username and password as created by our script, e.g. afp://username:password@server.domain.local/Share into the Finders 'Connect to Server' 'Server address:' field mounts the server without prompting even without the password in the keychain.

So the command DOES still work, just not when called from a script.

This is a real nuisance for us. I would really appreciate it if we could get a definitive answer if this very specific behaviour is a bug or a 'feature'.

[crbeck]

@cizdziem That makes it sound like the Applecare Support rep was confused what you were talking about. Like they were thinking of the Connect or Cancel box that pops up the first time you connect to a new share.

We're having the same issue as mentioned with SMB shares (Network Home for our AD users), latest round of security updates to Sierra, High Sierra, and Mojave 10.14.2 are to blame. Everything prior to the latest updates and the shares mount just fine. The typical scripts I had failed to connect to the shares, even with user authentication, unless the user manually did Connect to Server through Finder. Ended up making a simple script into an app to open the shares for now...

#!/bin/bash

loggedInUser=`/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }'`

homePath=$(dscl /Active Directory/AD/myadserver.org -read /Users/$loggedInUser SMBHome | sed 's/SMBHome: //' | sed 's/\///g') &> /dev/null

open .
sleep 1
osascript -e 'tell application "System Events"' -e 'keystroke "k" using command down' -e 'delay 0.5' -e 'keystroke "smb:"' -e "keystroke "$homePath"" -e 'keystroke return' -e 'end tell'

[cizdziem]

@crbeck Yes, I agree that it sounds like the Applecare Support rep was confused. Since that communication, I've had further correspondence with him that makes me confident he understands the scope of the issue. Additionally he stated that the engineering team said the "specific security consideration this change was made for impacted NTLM only. The current fix applies before any credentials are even checked (NTLM or kerberos)." The rep has a request submitted with the engineering team "to only show this prompt if a CIFS service ticket cannot be collected" but he warns that this modification wouldn't be simple due to other security concerns. He's also "arguing that training end users to ignore password prompts is problematic" (due to the fact that users don't actually have to provide a password when prompted to Connect, despite the presence of an empty password field).

I'd encourage anyone affected by this change to open an Applecare support case and/or file a Radar to help make the effects of these changes apparent to Apple.

[deploy2020]

@cizdziem It does sound like the Apple engineer understands the issue and their comments are't that encouraging. As @jordan.boden says, if Apple allowed us to create a 'whitelist' of allowed domains, perhaps with a config profile, then this 'fix' would solve the issue of preventing users from connecting to malicious links sent via email or in websites, but still allow enterprise/education customers to mount volumes with a script if they are calling a pre-approved domain. Much like they did with MDM Kernel Extension approval!

[killer23d]

We use NoMad to facilitate mounting the user's network share. We also want to echo the issue all the way from 10.14.2 to 10.12.6; once the newest security updates are installed. When mounting the share, normally the share will auto mount and opened to the user; now, there is another prompt and all the shares are visible to the user (prohibit signs obviously). The user then will have to figure out the absolute path. This creates a less-than-ideal situation for our lesser-savvy users.

We have submitted a ticket with JAMF about this and from the response, the problem is not unique.

[holger_netterby]

Hello

My co-worker erik.bille wrote the original post in this thread after we noticed this strange and irritating behaviour for a function we have been using since the dawn of time. Took some time before we realised this effected 10.12.6/006, 10.13.6/003 too and not just 10.14.2.

I have rewritten our mount procedures using a signed AppleScript .app (instead of open "afp://server/share") and using "open -g /path/to/mountserver.app" - takes more time initially packing and signing the AppleScript app but it does have a couple of advantages too. One being able to (re)mount the server in the background transparent without disturbing the user using the -g (do not bring app to front) key. The second being able to place these "servermount.app`s" in the dock for easy access for the user who never seems to learn how to find the server except in the Sidebar ;)

The mounting of the servers is done with a script triggered by two launchagents - one for network change and one for login of the user

[deploy2020]

Hello there Holger,

Thanks very much for posting your workaround. I use an AppleScript App to mount the server and I’m seeing the ‘issue’ discussed in this thread because the AppleScript calls an Open Location commad with the users credentials and path to the server.

Would you mind sharing the contents of your servermount.app so we can see what AppleScript commands you’re issuing please? I assume it isn’t:

tell application “Finder”
open location “afp://username:password@server.domain.com/sharename”
end tell

It would really help me and all my users to get this working again.

On a connected note, I’ve noticed that the ‘new’ behaviour of throwing up the ‘choose share’ dialogue actually presents the user with a list of ALL the shares on the server, irrespective of whether the connecting users account actually has permission to access them. This in my opinion presents a security risk by exposing the names of potentially sensitive shares to users without access permissions. If this ‘new’ behaviour is the default Apple really need to fix this permissions issue. Users without permission to a share shouldn’t be able to see it in the list, just as they can’t when using Connect to server from the Go menu.

[analog_kid]

I've found a mounting method that bypasses the issue. Use the AppleScript "mount volume" command:

mount volume "smb://my.server.here/share"

It also works fine in a shell script via osascript.

[holger_netterby]

Hello deploy2020

Below is the AppleScript I package as a signed run only app (the script is found somewhere in the internetz)

I see the same thing as you do with all shares on the server you want to connect to being shown using the old method with open "afp://server.test.com/sharesname"

1. Edit script below for your own taste (servers and shares)
2. Export as run only signed .app
3. Optional - put a nice icon on the app
4. Package with sudo pkgbuild --install-location /Library/customerXXX/Applications --component /Library/customerXXX/Applications/ServerShareName.app /path/to/outputfolder/com.companyxxx.server_mount_serversharename.app.pkg
5. Create LaunchAgents of your choice for when mounting is done (login, network change) and a script triggered by the LaunchAgent(s) for actually mounting the share. I use open -g "/Library/customerXXX/Applications/ServerShareName.app"
6. For 10.14.2 you have to create a TCC profile for this signed app to control System Events (allow)
7. Deploy LaunchAgent(s), script, TCC profile and .app with Jamf

There is probably easier ways of doing this but this method works for me :)

set networkUp to true
set freNetUp to true

set shareApplikation to "ShareName"
set shareApplikationMounted to false

try
    do shell script "ping -c1 www.google.com"
on error theError
    set networkUp to false
    display dialog "Computer not connected to the Internet"
    return theError

    if networkUp then
        try
            do shell script "ping -c 1 -t 2 IP_of_server"
        on error
            set freNetUp to false
        end try
    end if

end try

if freNetUp is true then

    tell application "System Events" to set diskNames to name of every disk

    if shareApplikation is in diskNames then
        set shareApplikationMounted to true

    else

        set shareApplikationMounted to false
        try
            mount volume "afp://server.test.com/" & shareApplikation
        end try

    end if

end if

[gmillercmsd12]

We are experiencing the same issues on AD SMB shares. However, we are testing nomad as an option for shares and it seems to not be affected by this security patch. If we move to use Nomad instead, then we have to figure out how to remove the dead link that is auto-created in the dock.

[svenke]

@holger.netterby are you sure about this part:

if freNetUp is true then tell application "System Events" to set diskNames to name of every disk if shareApplikation is in diskNames then set shareApplikationMounted to true else set shareApplikationMounted to false try mount volume "afp://server.test.com/" & shareApplikation end try end if end if

i'm receiving an error when i use this part. If i replace it with a simple mount volume "afp://server.test.com/" then the mount is working but i won't get a new window at the moment of mounting ??

[holger_netterby]

@svenke

I’m pretty sure it works for me. :)

What error do you get?

If you run the whole script in Apple ScriptEditor (or CodeRunner) what du you get?

It just a check for avoiding double-mounting of the share.

Basically it’s just a mount volume script with some extra trimmings and checks.

[svenke]

@holger.netterby

i found why it wasn't working here :) is there a way to still open a finder window displaying the share contents after it mounts?

[johnjrpcs]

I've also had issues with smb shares in the Dock not working on 10.13.6 since applying Security Update 2018-003 (High Sierra). I have logged a bug report with Apple which is currently with engineering.

For now as a work around I use mount volume smb://some.server/share/path in my scripts.

[cizdziem]

The macOS 10.14.3 beta fixes this issue for me. From the "Resolved Issues" section of the 10.14.3 release notes:

When making a file sharing connection, users would be prompted to enter credentials even if they had already obtained a Kerberos TGT. When attempting to directly mount a sub-folder located within a shared folder (e.g. smb://server.example.com/sharepoint/subfolder), users would be prompted to select the share point to mount. Starting in macOS 10.14.3 beta, users with a Kerberos TGT won't be prompted for credentials and the sub-folder will mount directly.

I've asked my AppleCare support rep if there are plans to apply this resolution to 10.12 and 10.13.

[yert33]

VERY interested to see what Apple says about applying the resolution to 10.12 and 10.13...

[cizdziem]

@yert33 In my testing, the issues described in this thread are corrected by the newly-released 2019-001 updates for Sierra and High Sierra.

[yert33]

Thanks, cizdziem. I'll look for them tomorrow after rehearsal.

[janselmi3953]

I can confirm that everything is working as usual with the 10.14.3 update. I have not yet tested 2019-001 for Sierra and High Sierra yet though.

[yert33]

Yup, those fixed it. Thanks again.

[crskerman]

@janselmi3953 I'm seeing 2019-001 fix the issue for High Sierra

[cizdziem]

I'm seeing these issues again with Sierra 2019-002 and High Sierra 2019-002. Submitted a bug report on the topic.

[Chris]

@cizdziem seeing the same. Do you have a Radar# to duplicate?

[cizdziem]

49294440, sorry, that would've been good info to include in my post yesterday!

[Michael_Meyers]

We have seen the same issue on both High Sierra and Mojave and were told by Apple that it is a bug. The 10.14.3 update fixed the issue in Mojave for us. We use an update server for all of our Apple updates, and I disabled the security update on High Sierra to stop it from happening on those Macs. It has been successful so far.

Our solution to our users is to either use our Erase/Install policy to "reimage" their Mac to High Sierra without that update, or wait till we have a Mojave upgrade available.

[Chris]

This seems to be fixed in the re-released updates
https://support.apple.com/en-us/HT209635