Microsoft Entra Kerberos is enabled for an Azure Files share, yet everyone who can mount it still sees every lock plan. What authorization layers should the security engineer configure?

When Microsoft Entra Kerberos is enabled for an Azure Files share yet everyone who can mount it still sees every lock plan, configure both authorization layers: share-level Azure RBAC such as Storage File Data SMB Share Reader, Contributor, or Elevated Contributor, then NTFS/ACL permissions on directories and files. Kerberos authenticates who you are; share RBAC decides whether you may access the share over SMB; NTFS ACLs refine which folders and files inside the share you may open. Elevated Contributor is the share role that can change NTFS permissions. Municipal lock plans need both layers so authentication alone does not equal full share visibility.

Using share-level Azure RBAC alone with no directory NTFS ACLs because Kerberos ignores file ACLs fails by concept: Kerberos does not remove NTFS authorization; without ACLs, share-level access is too coarse for per-folder lock plans. Using NTFS ACLs alone without any Storage File Data SMB share roles fails because share-level RBAC is required for identity-based SMB authorization—ACLs refine access after share access is granted. Using only the storage account key for SMB so RBAC and NTFS both become optional fails by abandoning the identity model and returning to an overpowered shared secret.

Exam caveat: identity-based Azure Files is explicitly two-layered (share RBAC + NTFS); Kerberos enablement is authentication, not a complete authorization design. Operational check: assign least-privilege Storage File Data SMB Share roles per team, apply NTFS ACLs so night shift cannot read unrelated lock-plan directories, verify a user with share access but denied NTFS cannot open restricted folders, and document Elevated Contributor holders who may change ACLs.