Merge branch 'MicrosoftDocs:main' into main

Author: bhaimicrosoft

articles/active-directory/fundamentals/media/active-directory-properties-area/active-directory-no-privacy-statement-or-contact.png

@@ -35,8 +35,8 @@ You add your organization's privacy information in the **Properties** area of Az
 
     The **Properties** area appears.
 
-    ![Azure AD Properties area highlighting the privacy info area](media/active-directory-properties-area/properties-area.png)
-
+    :::image type="content" source="media/active-directory-properties-area/properties-area.png" alt-text="Screenshot showing the properties area highlighting the privacy info area.":::
+ 
 3. Add your privacy info for your employees:
 
     - **Technical contact.** Type the email address for the person to contact for technical support within your organization.
@@ -48,7 +48,7 @@ You add your organization's privacy information in the **Properties** area of Az
         >[!Important]
         >If you don't include either your own privacy statement or your privacy contact, your external guests will see text in the **Review Permissions** box that says, **<_your org name_> has not provided links to their terms for you to review**. For example, a guest user will see this message when they receive an invitation to access an organization through B2B collaboration.
 
-        ![B2B Collaboration Review Permissions box with message](media/active-directory-properties-area/active-directory-no-privacy-statement-or-contact.png)
+        :::image type="content" source="media/active-directory-properties-area/no-privacy-statement-or-contact.png" alt-text="Screenshot showing the B2B Collaboration Review Permissions box with message.":::
 
 4. Select **Save**.
 

articles/active-directory/fundamentals/media/active-directory-properties-area/no-privacy-statement-or-contact.png

@@ -223,7 +223,7 @@
       items:
       - name: Create an NFS volume
         href: azure-netapp-files-create-volumes.md
-      - name: Configure NFSv4.1 domain
+      - name: Configure NFSv4.1 ID domain
         href: azure-netapp-files-configure-nfsv41-domain.md
       - name: Configure NFSv4.1 Kerberos encryption
         href: configure-kerberos-encryption.md

articles/active-directory/fundamentals/media/active-directory-properties-area/properties-area.png

@@ -1,6 +1,6 @@
 ---
-title: Configure NFSv4.1 domain for Azure NetApp Files | Microsoft Docs
-description: Describes how to configure NFSv4.1 domain for using NFSv4.1 with Azure NetApp Files.
+title: Configure NFSv4.1 ID domain for Azure NetApp Files | Microsoft Docs
+description: Learn how to configure NFSv4.1 ID domain for using NFSv4.1 with Azure NetApp Files.
 documentationcenter: ''
 author: b-hchen
 manager: ''
@@ -11,27 +11,77 @@ ms.service: azure-netapp-files
 ms.workload: storage
 ms.tgt_pltfrm: na
 ms.topic: how-to
-ms.date: 11/11/2021
+ms.date: 07/12/2023
 ms.author: anfdocs
 ---
-# Configure NFSv4.1 domain for Azure NetApp Files
+# Configure NFSv4.1 ID domain for Azure NetApp Files
 
-NFSv4 introduces the concept of an authentication domain. Azure NetApp Files currently supports root-only user mapping from the service to the NFS client. To use the NFSv4.1 functionality with Azure NetApp Files, you need to update the NFS client.
+NFSv4 introduces the concept of an ID authentication domain. Azure NetApp Files uses the entry value `defaultv4iddomain.com` as the authentication domain, and NFS clients use their own configuration to authenticate users that want to access files on those volumes. By default, NFS clients will use the DNS domain name as the NFSv4 ID domain. You can override this setting by using the NFSv4 configuration file named `idmapd.conf`. 
+
+If authentication domain settings on NFS client and Azure NetApp Files do not match, file access may be denied as the NFSv4 user and group mapping may fail. When this happens, the users and groups that do not match properly will squash the user and group configured in the `idmapd.conf` file (generally, nobody:99) and an event will be logged on the client.  
+
+This article explains the default behavior of user/group mapping and how to configure NFS clients correct to authenticate properly and allow access. 
 
 ## Default behavior of user/group mapping
 
-Root mapping defaults to the `nobody` user because the NFSv4 domain is set to `localdomain` by default. When you mount an Azure NetApp Files NFSv4.1 volume as root, you'll see file permissions as follows:  
+The root user mapping can illustrate what happens if there is a mismatch between the Azure NetApp Files and NFS clients. The installation process of an application often requires the use of the root user. Azure NetApp Files can be configured to allow access for `root`. 
+
+In the following directory listing example, the user `root` mounts a volume on a Linux client that uses its default configuration `localdomain` for the ID authentication domain, which is different from Azure NetApp Files’ default configuration of `defaultv4iddomain.com`.
+
+:::image type="content" source="../media/azure-netapp-files/azure-netapp-files-nfsv41-default-behavior-user-group-mapping.png" alt-text="Screenshot of file directory output." lightbox="../media/azure-netapp-files/azure-netapp-files-nfsv41-default-behavior-user-group-mapping.png":::
+
+In the listing of the files in the directory, `file1` shows as being mapped to `nobody`, when it should be owned by the root user. 
+
+There are two ways to adjust the authentication domain on both sides: Azure NetApp Files as NFS server and Linux as NFS clients: 
+
+1. **Central user management**: If you're already using a central user management such as Active Directory Domain Services (AD DS), you can configure their Linux clients to use LDAP and set the domain configured in AD DS as authentication domain. At the server side, you must enable the AD domain service for Azure NetApp Files and create LDAP-enabled volumes. The LDAP-enabled volumes automatically use the domain configured in AD DS as their authentication domain.
 
-![Default behavior of user/group mapping for NFSv4.1](../media/azure-netapp-files/azure-netapp-files-nfsv41-default-behavior-user-group-mapping.png)
+    For more information about this process, see [Enable Active Directory Domain Services (AD DS) LDAP authentication for NFS volumes](configure-ldap-extended-groups.md). 
 
-As the above example shows, the user for `file1` should be `root`, but it maps to `nobody` by default.  This article shows you how to set the `file1` user to `root` by changing the `idmap Domain` setting to `defaultv4iddomain.com`.  
+1. **Manually configure the Linux client**: If you are not using a central user management for your Linux clients, you can manually configure the Linux clients to match the default authentication domain of Azure NetApp Files for non-LDAP enabled volumes.  
 
-## Configure NFSv4.1 domain  
+In this section we’ll focus on how to configure the Linux client and how to change the Azure NetApp Files authentication domain for all non-LDAP enabled volumes. 
+
+## Configure NFSv4.1 ID domain on Azure NetApp Files
+
+You can specify a desired NFSv4.1 ID domain for all non-LDAP volumes using the Azure portal. This setting applies to all non-LDAP volumes across all NetApp accounts in the same subscription and region. It does not affect LDAP-enabled volumes in the same NetApp subscription and region. 
+
+### Register the feature
+
+Azure NetApp Files supports the ability to set the NFSv4.1 ID domain for all non-LDAP volumes in a subscription using the Azure portal. This feature is currently in preview. You need to register the feature before using it for the first time. After registration, the feature is enabled and works in the background.
+
+1.  Register the feature
+
+    ```azurepowershell-interactive
+    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain
+    ```
+
+2. Check the status of the feature registration: 
+
+    > [!NOTE]
+    > The **RegistrationState** may be in the `Registering` state for up to 60 minutes before changing to `Registered`. Wait until the status is `Registered` before continuing.
+
+    ```azurepowershell-interactive
+    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain
+    ```
+You can also use [Azure CLI commands](/cli/azure/feature) `az feature register` and `az feature show` to register the feature and display the registration status. 
+
+### Steps
+
+1. Under the Azure NetApp Files subscription, select **NFSv4.1 ID Domain**.
+1. Select **Configure**.
+1. To use the default domain `defaultv4iddomain.com`, select the box next to **Use Default NFSv4 ID Domain**. To use another domain, uncheck the text box and provide the name of the NFSv4.1 ID domain.
+
+    :::image type="content" source="../media/azure-netapp-files/nfsv4-id-domain.png" alt-text="Screenshot with field to set NFSv4 domain." lightbox="../media/azure-netapp-files/nfsv4-id-domain.png":::
+
+1. Select **Save**.
+
+### Configure NFSv4.1 ID domain in NFS clients
 
 1. Edit the `/etc/idmapd.conf` file on the NFS client.   
     Uncomment the line `#Domain` (that is, remove the `#` from the line), and change the value `localdomain` as follows:
 
-    * If the volume isn’t enabled for LDAP, set `Domain = defaultv4iddomain.com`.
+    * If the volume isn't enabled for LDAP, either use the default domain `defaultv4iddomain.com` by specifying `Domain = defaultv4iddomain.com`, or specify the NFSv4.1 ID domain as [configured in Azure NetApp Files](#steps). 
     * If the volume is [enabled for LDAP](configure-ldap-extended-groups.md), set `Domain` to the domain that is configured in the Active Directory Connection on your NetApp account.
         For instance, if `contoso.com` is the configured domain in the NetApp account, then set `Domain = contoso.com`.
 
@@ -49,7 +99,7 @@ As the above example shows, the user for `file1` should be `root`, but it maps t
     Nobody-Group = nogroup 
     ```
 
-    The following example shows updated configuration of *non-LDAP* NFSv4.1 volumes:
+    The following example shows updated configuration of *non-LDAP* NFSv4.1 volumes for default domain `defaultv4iddomain.com`:
 
     ```
     [General]
@@ -92,18 +142,19 @@ As the example shows, the user/group has now changed from `nobody` to `root`.
 
 ## Behavior of other (nonroot) users and groups
 
-Azure NetApp Files supports local users (users created locally on a host) who have permissions associated with files or folders in NFSv4.1 volumes. However, the service doesn't currently support mapping the users/groups across multiple nodes. Therefore, users created on one host don't map by default to users created on another host. 
+Azure NetApp Files supports local users and groups (created locally on the NFS client and represented by user and group IDs) and corresponding ownership and permissions associated with files or folders in NFSv4.1 volumes. However, the service doesn't automatically solve for mapping local users and groups across NFS clients. Users and groups created on one host may or may not exist on another NFS client (or exist with different user and group IDs), and will therefore not map correctly as outlined in the example below.
 
-In the following example, `Host1` has three existing test user accounts (`testuser01`, `testuser02`, `testuser03`): 
+In the following example, `Host1` has three user accounts (`testuser01`, `testuser02`, `testuser03`): 
 
 ![Screenshot that shows that Host1 has three existing test user accounts.](../media/azure-netapp-files/azure-netapp-files-nfsv41-host1-users.png)
 
-On `Host2`, the test user accounts haven't been created, but the same volume is mounted on both hosts:
+On `Host2`, no corresponding user accounts exist, but the same volume is mounted on both hosts:
 
 ![Resulting configuration for NFSv4.1](../media/azure-netapp-files/azure-netapp-files-nfsv41-host2-users.png)
 
-## Next step 
+To resolve this issue, either create the missing accounts on the NFS client or configure your NFS clients to use the LDAP server that Azure NetApp Files is using for centrally managed UNIX identities. 
+
+## Next steps
 
 * [Mount a volume for Windows or Linux VMs](azure-netapp-files-mount-unmount-volumes-for-virtual-machines.md)
 * [Configure AD DS LDAP with extended groups for NFS volume access](configure-ldap-extended-groups.md)
-

articles/active-directory/fundamentals/properties-area.md

@@ -35,8 +35,8 @@ This article shows you how to create an NFS volume. For SMB volumes, see [Create
 * Security  
   Support for UNIX mode bits (read, write, and execute) is available for NFSv3 and NFSv4.1. Root-level access is required on the NFS client to mount NFS volumes.
 
-* Local user/group and LDAP support for NFSv4.1  
-  Currently, NFSv4.1 supports root access to volumes only. See [Configure NFSv4.1 default domain for Azure NetApp Files](azure-netapp-files-configure-nfsv41-domain.md). 
+* User ID mapping in NFSv4.1 for LDAP-enabled and non-LDAP volumes  
+  To avoid permission issues, including access for a root user, when using NFSv4.1, the ID domain configuration on the NFS client and Azure NetApp Files must match. User ID mapping can use centralized user management with LDAP or use local users for non-LDAP volumes. To configure the ID Domain in Azure NetApp Files for non-LDAP volumes, see [Configure NFSv4.1 ID domain for Azure NetApp Files](azure-netapp-files-configure-nfsv41-domain.md). 
 
 ## Best practice
 

articles/azure-netapp-files/TOC.yml

@@ -12,7 +12,7 @@ ms.service: azure-netapp-files
 ms.workload: storage
 ms.tgt_pltfrm: na
 ms.topic: how-to
-ms.date: 02/21/2023
+ms.date: 03/17/2023
 ms.author: anfdocs
 ---
 # Enable Active Directory Domain Services (AD DS) LDAP authentication for NFS volumes
@@ -26,25 +26,25 @@ Azure NetApp Files supports fetching of extended groups from the LDAP name servi
 
 When it’s determined that LDAP will be used for operations such as name lookup and fetching extended groups, the following process occurs:
 
-1. Azure NetApp Files uses an LDAP client configuration to make a connection attempt to the ADDS/AADDS LDAP server that is specified in the [Azure NetApp Files AD configuration](create-active-directory-connections.md).
-1. If the TCP connection over the defined ADDS/AADDS LDAP service port is successful, then the Azure NetApp Files LDAP client attempts to “bind” (sign in) to the ADDS/AADDS LDAP server (domain controller) by using the defined credentials in the LDAP client configuration.
-1. If the bind is successful, then the Azure NetApp Files LDAP client uses the RFC 2307bis LDAP schema to make an LDAP search query to the ADDS/AADDS LDAP server (domain controller).
+1. Azure NetApp Files uses an LDAP client configuration to make a connection attempt to the AD DS/Azure AD DS LDAP server that is specified in the [Azure NetApp Files AD configuration](create-active-directory-connections.md).
+1. If the TCP connection over the defined AD DS/Azure AD DS LDAP service port is successful, then the Azure NetApp Files LDAP client attempts to “bind” (sign in) to the AD DS/Azure AD DS LDAP server (domain controller) by using the defined credentials in the LDAP client configuration.
+1. If the bind is successful, then the Azure NetApp Files LDAP client uses the RFC 2307bis LDAP schema to make an LDAP search query to the AD DS/Azure AD DS LDAP server (domain controller).
 The following information is passed to the server in the query:
    * [Base/user DN](configure-ldap-extended-groups.md#ldap-search-scope) (to narrow search scope)
    * Search scope type (subtree)
    * Object class (`user`, `posixAccount` for users, and `posixGroup` for groups)
    * UID or username 
    * Requested attributes (`uid`, `uidNumber`, `gidNumber` for users, or `gidNumber` for groups) 
 1. If the user or group isn’t found, the request fails, and access is denied.
-1. If the request is successful, then user and group attributes are [cached for future use](configure-ldap-extended-groups.md#considerations). This operation improves the performance of subsequent LDAP queries associated with the cached user or group attributes. It also reduces the load on the ADDS/AADDS LDAP server.
+1. If the request is successful, then user and group attributes are [cached for future use](configure-ldap-extended-groups.md#considerations). This operation improves the performance of subsequent LDAP queries associated with the cached user or group attributes. It also reduces the load on the AD DS/Azure AD DS LDAP server.
 
 ## Considerations
 
 * You can enable the LDAP with extended groups feature only during volume creation. This feature can't be retroactively enabled on existing volumes.  
 
-* LDAP with extended groups is supported only with Active Directory Domain Services (AD DS) or Azure Active Directory Domain services (AADDS). OpenLDAP or other third-party LDAP directory services aren't supported. 
+* LDAP with extended groups is supported only with Active Directory Domain Services (AD DS) or Azure Active Directory Domain services (Azure AD DS). OpenLDAP or other third-party LDAP directory services are not supported. 
 
-* LDAP over TLS must *not* be enabled if you're using Azure Active Directory Domain Services (AADDS).  
+* LDAP over TLS must *not* be enabled if you are using Azure Active Directory Domain Services (Azure AD DS).  
 
 * You can't modify the LDAP option setting (enabled or disabled) after you've created the volume.  
 
@@ -82,6 +82,9 @@ The following information is passed to the server in the query:
 
     The values specified for `objectClass` are separate entries. For example, in Multi-valued String Editor, `objectClass` would have separate values (`user` and `posixAccount`) specified as follows for LDAP users:   
 
+    >[!NOTE]
+    >If the POSIX attributes are not set up correctly, user and group lookup operations may fail, and users may be squashed to `nobody` when accessing NFS volumes. 
+
     ![Screenshot of Multi-valued String Editor that shows multiple values specified for Object Class.](../media/azure-netapp-files/multi-valued-string-editor.png) 
 
     You can manage POSIX attributes by using the Active Directory Users and Computers MMC snap-in. The following example shows the Active Directory Attribute Editor. See [Access Active Directory Attribute Editor](create-volumes-dual-protocol.md#access-active-directory-attribute-editor) for details.  
@@ -90,7 +93,7 @@ The following information is passed to the server in the query:
 
 4. If you want to configure an LDAP-integrated NFSv4.1 Linux client, see [Configure an NFS client for Azure NetApp Files](configure-nfs-clients.md).
 
-5. If your LDAP-enabled volumes use NFSv4.1, follow instructions in [Configure NFSv4.1 domain](azure-netapp-files-configure-nfsv41-domain.md#configure-nfsv41-domain) to configure the `/etc/idmapd.conf` file.
+5. If your LDAP-enabled volumes use NFSv4.1, follow instructions in [Configure NFSv4.1 ID domain](azure-netapp-files-configure-nfsv41-domain.md#configure-nfsv41-id-domain-in-nfs-clients) to configure the `/etc/idmapd.conf` file.
 
     You need to set `Domain` in `/etc/idmapd.conf` to the domain that is configured in the Active Directory Connection on your NetApp account. For instance, if `contoso.com` is the configured domain in the NetApp account, then set `Domain = contoso.com`.
 
@@ -123,7 +126,7 @@ The following information is passed to the server in the query:
 
 * [Create an NFS volume for Azure NetApp Files](azure-netapp-files-create-volumes.md)
 * [Create and manage Active Directory connections](create-active-directory-connections.md)
-* [Configure NFSv4.1 domain](azure-netapp-files-configure-nfsv41-domain.md#configure-nfsv41-domain)
+* [Configure NFSv4.1 domain](azure-netapp-files-configure-nfsv41-domain.md)
 * [Configure an NFS client for Azure NetApp Files](configure-nfs-clients.md)
 * [Troubleshoot volume errors for Azure NetApp Files](troubleshoot-volumes.md)
 * [Modify Active Directory connections for Azure NetApp Files](modify-active-directory-connections.md)