Merge pull request #313068 from khdownie/patch-7

Clarify Windows ACLs configuration requirements

Author: prmerger-automator[bot]

articles/storage/files/storage-files-identity-configure-file-level-permissions.md

@@ -13,14 +13,16 @@ ms.author: kendownie
 
 **Applies to:** :heavy_check_mark: SMB file shares
 
-Before you can configure directory and file-level permissions, you must [assign share-level permissions to an identity](storage-files-identity-assign-share-level-permissions.md) with Azure role-based access control (RBAC). After the share-level permissions propagate, you can configure Windows access control lists (ACLs), also known as NTFS permissions, at the root, directory, or file level.
+Before you can configure directory and file-level permissions, you must [assign share-level permissions to an identity](storage-files-identity-assign-share-level-permissions.md) with Azure role-based access control (RBAC). After the share-level permissions propagate, you can configure Windows access control lists (ACLs), also known as NTFS permissions, as described in this article.
+
+Before you can configure Windows ACLs, you need to mount the file share with admin-level access.
 
 > [!IMPORTANT]
 > To configure Windows ACLs for [hybrid identities](/entra/identity/hybrid/whatis-hybrid-identity), you need a client machine running Windows that has unimpeded network connectivity to the domain controller. If you authenticate with Azure Files using Active Directory Domain Services (AD DS) or Microsoft Entra Kerberos for hybrid identities, you need unimpeded network connectivity to the on-premises Active Directory. If you use Microsoft Entra Domain Services, the client machine must have unimpeded network connectivity to the domain controllers for the domain that's managed by Microsoft Entra Domain Services, which are located in Azure. For cloud-only identities (preview), there's no dependency on domain controllers, but the client device must be joined to Microsoft Entra ID.
 
 ## How Azure RBAC and Windows ACLs work together
 
-While share-level permissions (RBAC) act as a high-level gatekeeper that determines whether a user can access the share, Windows ACLs (NTFS permissions) operate at a more granular level to control what operations the user can do at the directory or file level.
+While share-level permissions (RBAC) act as a high-level gatekeeper that determines whether a user can access the share, Windows ACLs (NTFS permissions) operate at a more granular level to control what operations the user can do at the directory or file level. You can set Windows ACLs at the root, directory, or file level.
 
 When a user tries to access a file or directory, both share-level and file/directory-level permissions are enforced. If there's a difference between either of them, only the most restrictive one applies. For example, if a user has read/write access at the file level, but only read at a share level, they can only read that file. The same rule applies if the permissions are reversed: if a user has read/write access at the share level, but only read at the file level, they can still only read the file.
 
@@ -72,7 +74,7 @@ Before you configure Windows ACLs, mount the file share with admin-level access.
 - **Use the storage account key (less secure)**: Use your storage account key to mount the file share and then configure ACLs. The storage account key is a sensitive credential. For security reasons, use this option only if you can't use identity-based authentication.
 
 > [!NOTE]
-> If a user has the **Full Control** ACL as well as the [Storage File Data SMB Share Elevated Contributor](/azure/role-based-access-control/built-in-roles/storage#storage-file-data-smb-share-elevated-contributor) role (or a custom role with the required permissions), they can configure ACLs without using the Windows permission model for SMB admin or the storage account key.
+> If a user has the **Full Control** ACL as well as the [Storage File Data SMB Share Elevated Contributor](/azure/role-based-access-control/built-in-roles/storage#storage-file-data-smb-share-elevated-contributor) role (or a custom role with the required permissions), then they can configure ACLs without using the Windows permission model for SMB admin or the storage account key.
 
 ### Use the Windows permission model for SMB admin