Permissions Issues with macOS Server Network Account under Active Directory
We recently had a call from a school running a suite of iMacs on macOS Mojave 10.14.6.
As is often the case, the previous Mac consultant had retired or disappeared for some other reason. This left the client without a solution provider to manage ongoing upgrades and Mac system maintenance.
The client called us because, after a recent re-image of their base macOS system, they noticed that students could suddenly access each other’s files on the main server.
Knowing very well that a group of teenagers would very quickly find 1000 practical jokes of varying degrees of offensiveness, taking advantage of this permissions problem, we were asked to fix the issue as quickly as possible.
It turns out that all the student home folders were kept inside a single shared folder on the Windows server, which is fairly typical. The Macs were bound to Active Directory in the usual way though System Preferences > Users and Group > Login Options (which essentially is a quick setup that might otherwise require the Directory Utility app for more complex environments).
When a student logged into the Mac with their Active Directory credentials, they would see not only their network home folder mounted on the desktop (this was auto-mounted using a login script) but would ALSO see the parent folder, containing all the other students’ home folders.
It didn’t take long to notice that a given student could access those other students’ home folders.
Active Directory binding
After some rummaging around, we noticed that the DeployStudio image being used had a checkbox relating to the Active Directory binding, which would usually only be visible in the Directory Utility app, if you were to interrogate the settings of the AD binding. The checkbox says “Use UNC path from Active Directory to derive network home location”.
With this box checked, the macOS client was retrieving a path to the student home folder parent directory, which was being defined by the AD server, and automatically mounting it. As such, any student could easily browse to other student’s home folders. Simply unticking this box on each of the macOS client machines stopped this behaviour from happening.
However, this wasn’t the end of the story. It occurred to us that really, even if the student couldn’t see their peers’ home folders, there must still be a permissions issue. If a student happened to know the network path to type in, not too difficult, they could in theory still access other students’ folders if they have permission. So, what was going on?
After some investigation it transpired that the IT company who managed the Active Directory infrastructure was using Group Policy restrictions to disallow Windows PC users from browsing each others’ home folders. This was working quite effectively on Windows. However, GPO does not apply to macOS workstations and this was masking an underlying issue where the user home folders were not having the correct permissions set on them.
You might reasonably expect a student to own their home folder and its contents, with staff members able to read/write, but nobody else able to access it. In our case, the permissions were being inherited very erratically such that most students could access each others’ folders due to a very open read/write permission on the parent folder. But the Windows-centric IT provider was using Group Policy to prevent unauthorised access, rather than getting the core permissions right in the first place, thus masking an underlying problem.
So, two points to take home here. Firstly, make sure if you’re in a mixed macOS and Windows environment that your Windows file server permissions are kosher and set correctly. Don’t rely on Group Policy to manage access restrictions in a mixed environment. If you struggle to get the permissions and inheritance formula right, you probably need to consider restructuring your folders to make your job easier. Secondly, remember the UNC Path checkbox on macOS bindings will, often, mount the parent folder of your network homes in addition to the user’s home folder itself (depending on your specific AD setup). This may or may not be desirable behaviour, but it’s easy to control if you know how.