Open Permissions on a Client File Share Before a Contractor Onboards
Havenbrook is a 70-person marketing agency with an on-premises file server. The client deliverables share is mapped for everyone as drive S:. Its share permission is Everyone: Change, and the NTFS permissions inherited from the volume root are Domain Users: Modify. Client folders are nested one level under the share root and were created ad hoc, so each folder's inherited permissions were sometimes broken by whoever created it. No access review has been run since the server was built. Next Monday a contractor joins for a twelve-week campaign and needs read/write access to exactly one client folder, which also contains two years of that client's unreleased product photography. Separately, an account for a designer who left six weeks ago is still enabled because her manager asked to keep it 'in case we need her files.' The agency's largest client has just asked for written confirmation of who can access its materials.
1. Explain the effective permissions a newly hired employee currently receives on the share, and why the current split between share and NTFS permissions is the wrong shape.
Read the worked answer
Effective access is the most restrictive of share and NTFS, so a new employee in Domain Users gets: share = Change, NTFS = Modify, effective = Modify. That is read, write, and delete across every client folder, including folders where inheritance was broken and permissions were loosened rather than tightened. The departed designer's still-enabled account gets the same.
The design flaw is that both layers are open, so neither is doing the job. Best practice is to make the share permission permissive and uninteresting - Everyone: Full Control or Authenticated Users: Change - and let NTFS do all the real enforcement, because NTFS is granular, auditable, and survives being copied between volumes. Right now the share grants Change to Everyone, which means anyone who can authenticate, including guests and service accounts, has a path in; the only thing stopping them is NTFS, and NTFS has been edited ad hoc for years with no review.
Fixing this is not a permissions tweak, it is a rebuild of the access model. Do not simply tighten the share to Domain Users: Change and declare victory - that leaves every existing inherited and broken ACE in place and produces a false sense of control in the written confirmation the client is about to receive.
2. Design the contractor's access. What should be true of the account, the group, and the folder, and how do you avoid granting access to the unreleased photography beyond the campaign scope?
Read the worked answer
Account: a named contractor account, not a shared one, with a defined end date set in the directory, MFA required, and no membership in Domain Users beyond the default - build a separate baseline group if the domain requires one.
Group: one security group per client engagement, e.g. FS-CLIENTACME-CAMPAIGN-2024. Grant access to the group, never to the individual. When the engagement ends, you remove one membership and produce a clean audit line for the client.
Folder: stop inheriting on the campaign subfolder only, not the client root. Give the group Modify on the campaign subfolder and leave the photography archive with read-only or no access for that group. If the archive must be readable, split it into a sibling folder with its own group.
Avoiding the photography problem: the underlying risk is that 'one client folder' mixes campaign work and unreleased assets with different sensitivity. The judgement call is to restructure at the folder level before onboarding, not to rely on permissions within a folder - NTFS cannot hide files inside a folder from someone who can read the folder.
Verification: log in as the contractor (or use effective-access reporting) and confirm the archive is inaccessible before day one. A permissions change confirmed only in the GUI is not confirmed.
3. The client wants written confirmation of who can access its materials. Outline the audit you would run and how you would handle the departed designer's account, given the manager's request.
Read the worked answer
Audit first, confirm second. Produce, per client folder: the security groups and users with explicit ACEs, the users inheriting from the root, and anyone with access through a broken-inheritance exception. Cross-reference against the HR roster to surface accounts belonging to leavers or never-provisioned users. Use effective-access or access-reporting tooling rather than reading the ACL by eye - nested groups are where the surprises live. Export the result with a date so the confirmation has a baseline.
Handle the leaver deliberately. Disable the account and revoke sessions today; keep it disabled rather than deleting, so the SID still resolves on files she owned and mail can be forwarded for a defined period. Then transfer ownership of her files to her manager and give the manager access through a group, not by re-enabling an account. 'In case we need her files' is a file-access request, not an account request, and should be answered that way. Set a 90-day review date to delete.
Report honestly. Tell the client what access exists today, what you are changing, and by when. A confirmation that says 'reviewed and correct' before the remediation is complete is the one statement that turns a permissions problem into a contractual one. Include the contractor's time-limited group in the statement as evidence of a controlled process.