Disable Create Network function

[khey]

Hi guys,

can you please advise how to disable the "Create Network" function over Wi-Fi?

the reason is, we use proxy server in our network and we dont want somebody to create a new Access Point and piggybacking the access over the user who created the network.

thank you.

[davidacland]

Can they do it if they are non-admins?

A heavy handed way would be to block the network system preference pane. If that is blocked, can they still do it from the menu bar?

The last resort would be to remove the icon from the menu bar as well.

[khey]

yes, they still can do it.

i would like to remove the setting/icon from the menu bar if possible.

another thing that i can think of is to kill the process when a network is created.

[mm2270]

You may want to take a look at this thread:
https://jamfnation.jamfsoftware.com/discussion.html?id=14603

This only works if the users don't have admin rights. If they do, there isn't a good way to stop this that I know of.

[khey]

thanks @mm2270

at the moment, all mac users have admin right to their machines. hopefully someone can tell me how to make the option hidden for the very least?

thanks

[mm2270]

@khey If users have admin rights, stopping this is not going to be easy. Once someone has admin rights, all bets are off in terms of what you can control. Its just the nature of the beast.

That being said, I do like a challenge, and I took a look at this to see what you might be able to do. Although I don't know of any way to actually remove the "Create Network" item from the Wi-Fi menu or the Network Pref Pane, I found that when creating a network, it seems only 1 file is affected by this. Its /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist
Upon examining this closer it seems that, in my case anyway, a single setting (2 lines) gets removed from the plist when I create a network on my Mac. The key from the plist that disappears is "Workgroup" and the associated string for it, which happens to be our AD domain name. I'm not sure if this is going to be the same case with your Macs. You'll need to turn it on and see how that file gets changed before and after to see.

Assuming the same Workgroup key is present when no computer to computer network is on, and disappears once one is enabled, you may have luck with a LaunchDaemon and a local script to stop this.

Here's what I put together and tested and it seems to work to disable the comp to comp network after its turned on.

First the plist for the LaunchDaemon

<?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>Label</key>
    <string>com.domain.nobridge</string>
    <key>Program</key>
    <string>/Library/Scripts/nobridge.sh</string>
    <key>RunAtLoad</key>
    <true/>
    <key>ThrottleInterval</key>
    <integer>10</integer>
    <key>WatchPaths</key>
    <array>
        <string>/Library/Preferences/SystemConfiguration/com.apple.smb.server.plist</string>
    </array>
</dict>
</plist>

As you can see, it uses a WatchPath of /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist so it watches that single file for any changes. As soon as it sees any change, it runs the script referred to in the Program string, which looks like this (edited to change our domain name to a generic one)

#!/bin/sh

PLIST="/Library/Preferences/SystemConfiguration/com.apple.smb.server.plist"

WIFI=$(networksetup -listallhardwareports | awk '/Wi-Fi|AirPort/{getline; print $NF}')

WORKGROUP_DETECTION=$(defaults read "$PLIST" Workgroup 2>/dev/null)

if [[ -z "$WORKGROUP_DETECTION" ]] || [[ "$WORKGROUP_DETECTION" != "DOMAIN" ]]; then
    ## Disable power to Wi-Fi
    networksetup -setairportpower $WIFI off

    ## Fix the plist file
    defaults write "$PLIST" Workgroup "DOMAIN"
    sleep 1
    networksetup -setairportpower $WIFI on
else
    exit 0
fi

So the basic idea of the script above is, as soon as it runs it looks to see if there is a key in the plist for "Workgroup" If that key is either missing, or not set to what we expect it to be, it first disables power to Wi-Fi, then rewrites the correct Workgroup value into the plist, waits 1 second and finally, turns Wi-Fi back on. If your Macs are configured to auto connect to an access point like ours are, this reconnects it back to its default Wi-Fi AP. If they aren't configured to connect with a certificate or saved credentials, then they may be prompted to re-authenticate to an access point.

You can give the above items a try. Edit the script so it matches what Workgroup value it should be set to, and you can place the script wherever you want. Just be sure to edit the LaunchDaemon file's Program path appropriately to match it.

Last thing is, if you wanted to take this a step further, you could send up a dialog after it reverts the setting, explaining that creating computer to computer networks is restricted in your environment due to security requirements, or something to that effect. I'm a big advocate for informing end users why something will not work, not just stopping them from doing it, and not explaining why. For one, its about basic respect for our clients. Secondly, I've often found that a simple explanation of why something isn't allowed can go a long way. They often 'get it' and don't try doing it again once they understand the implications and that the organization specifically forbids it, even if they don't like the decision. So, just something to consider adding in if you wanted to.

If someone chimes in with a way to actually remove that functionality completely from the Wi-Fi menu, that would be the better option, but assuming there isn't a way to do that, you might have to use an approach like above. Keep in mind of course that since your users are admins, they can always disable the LaunchDaemon/script items if they discover them. I would set up a pretty generic sounding label for the launchd job so it doesn't call attention to what its actually doing.

[mm2270]

Just as a follow up, forget about the above method. I've tested it a little further and its not reliable. For instance, when I'm connected to our company VPN over AnyConnect, the Workgroup key gets removed from the plist file and it constantly triggers this script to run. So that plist gets modified under too many circumstances that are not strictly when a computer to computer network is created to rely on it. Maybe there's some other more reliable method, but it doesn't look like it at the moment.