Merge pull request #197224 from khdownie/kendownie050522

Adding wildcard warning

Author: PRMerger8

articles/storage/files/storage-files-identity-ad-ds-assign-permissions.md

@@ -5,7 +5,7 @@ author: khdownie
 ms.service: storage
 ms.subservice: files
 ms.topic: how-to
-ms.date: 03/16/2022
+ms.date: 05/04/2022
 ms.author: kendownie 
 ms.custom: devx-track-azurepowershell, subject-rbac-steps, devx-track-azurecli 
 ms.devlang: azurecli
@@ -53,6 +53,9 @@ The following table lists the share-level permissions and how they align with th
 
 If you intend to use a specific Azure AD user or group to access Azure file share resources, that identity must be a **hybrid identity that exists in both on-premises AD DS and Azure AD**. For example, say you have a user in your AD that is [email protected] and you have synced to Azure AD as [email protected] using Azure AD Connect sync. For this user to access Azure Files, you must assign the share-level permissions to [email protected]. The same concept applies to groups or service principals.
 
+> [!IMPORTANT]
+> **Assign permissions by explicitly declaring actions and data actions as opposed to using a wildcard (\*) character.** If a custom role definition for a data action contains a wildcard character, all identities assigned to that role are granted access for all possible data actions. This means that all such identities will also be granted any new data action added to the platform. The additional access and permissions granted through new actions or data actions may be unwanted behavior for customers using wildcard. To mitigate any unintended future impact, we highly recommend declaring actions and data actions explicitly as opposed to using the wildcard.
+
 In order for share-level permissions to work, you must:
 
 - Sync the users **and** the groups from your local AD to Azure AD using Azure AD Connect sync

includes/storage-files-aad-permissions-and-mounting.md

@@ -5,14 +5,14 @@
  author: roygara
  ms.service: storage
  ms.topic: include
- ms.date: 08/26/2020
+ ms.date: 05/06/2022
  ms.author: rogara
  ms.custom: include file, devx-track-azurecli, devx-track-azurepowershell
 ---
 
 ## Assign access permissions to an identity
 
-To access Azure Files resources with identity based authentication, an identity (a user, group, or service principal) must have the necessary permissions at the share level. This process is similar to specifying Windows share permissions, where you specify the type of access that a particular user has to a file share. The guidance in this section demonstrates how to assign read, write, or delete permissions for a file share to an identity. 
+To access Azure Files resources with identity based authentication, an identity (a user, group, or service principal) must have the necessary permissions at the share level. This process is similar to specifying Windows share permissions, where you specify the type of access that a particular user has to a file share. The guidance in this section demonstrates how to assign read, write, or delete permissions for a file share to an identity. **We highly recommend assigning permissions by declaring actions and data actions explicitly as opposed to using the wildcard (\*) character.**
 
 We have introduced three Azure built-in roles for granting share-level permissions to users:
 
@@ -32,6 +32,9 @@ The general recommendation is to use share level permission for high level acces
 
 ### Assign an Azure role to an AD identity
 
+> [!IMPORTANT]
+> **Assign permissions by explicitly declaring actions and data actions as opposed to using a wildcard (\*) character.** If a custom role definition for a data action contains a wildcard character, all identities assigned to that role are granted access for all possible data actions. This means that all such identities will also be granted any new data action added to the platform. The additional access and permissions granted through new actions or data actions may be unwanted behavior for customers using wildcard.
+
 # [Portal](#tab/azure-portal)
 To assign an Azure role to an Azure AD identity, using the [Azure portal](https://portal.azure.com), follow these steps: