Update lightweight-directory-access-protocol.md

Moving the section to the end

Author: netapp-manishc

articles/azure-netapp-files/lightweight-directory-access-protocol.md

@@ -124,32 +124,6 @@ Name mapping rules can be broken down into two main types: *symmetric* and *asym
 
 By default, Azure NetApp Files uses symmetric name mapping rules. If asymmetric name mapping rules are required, consider configuring the LDAP user objects to use them.
 
-## Allow local NFS users with LDAP
-
-When a user attempts to access an Azure NetApp Files volume via NFS, the request comes in a numeric ID. By default, Azure NetApp Files supports extended group memberships for NFS users (to go beyond the standard 16 group limit). As a result, Azure NetApp files will attempt to take that numeric ID and look it up in LDAP in an attempt to resolve the group memberships for the user rather than passing the group memberships in an RPC packet. Due to this behavior, if that numeric ID cannot be resolved to a user in LDAP, the lookup will fail and access will be denied – even if the requesting user has permission to access the volume or data structure. The Allow local NFS users with LDAP option in Active Directory connections is intended to disable those LDAP lookups for NFS requests by disabling the extended group functionality. It doesn't provide “local user creation/management” within Azure NetApp Files.
-
-When “Allow local NFS users with LDAP” option is enabled, numeric IDs are passed to Azure NetApp Files and no LDAP lookup is performed. This creates varying behavior for different scenarios, as covered below.
-
-### NFSv3 with UNIX security style volumes
-
-Numeric IDs don't need to be translated to user names. The “Allow local NFS users with LDAP” option will not impact access to the volume but may impact how user/group ownership (name translation) is displayed on the NFS client. For instance, if a numeric ID of 1001 is user1 in LDAP, but is user2 on the NFS client’s local passwd file, the client will display “user2” as the owner of the file when the numeric ID is 1001.
-
-### NFSv4.1 with UNIX security style volumes:
-Numeric IDs don't need to be translated to user names. By default, NFSv4.1 uses name strings ([email protected]) for its authentication. However, Azure NetApp Files supports the use of numeric IDs with NFSV4.1, which means that NFSv4.1 requests will arrive to the NFS server with a numeric ID. If no numeric ID to user name translation exists in local files or name services like LDAP for the Azure NetApp Files volume, then the numeric is presented to the client. If a numeric ID translates to a user name, then the name string will be used. If the name string doesn't match, the client will squash the name to the anonymous user specified in the client’s idmapd.conf file. Enabling the “Allow local NFS users with LDAP” option will not impact NFSv4.1 access, as it will fall back to standard NFSv3 behavior unless Azure NetApp Files can resolve a numeric ID to a user name in its local NFS user database. Azure NetApp Files has a set of default UNIX users that can be problematic for some clients and squash to a “nobody” user if domain ID strings do not match.
-* Local users include: root (0), pcuser (65534), nobody (65535).
-* Local groups include: root (0), daemon (1), pcuser (65534), nobody (65535).
-  
-Most commonly, root may show incorrectly in NFSv4.1 client mounts when the NFSv4.1 domain ID is misconfigured. For more information on the NFSv4.1 ID domain, see [Configuring NFSv4.1 ID domain for Azure NetApp Files](https://www.youtube.com/watch?v=UfaJTYWSVAY). 
-
-NFSv4.1 ACLs can be configured using either a name string or a numeric ID. If numeric IDs are used, no name translation is required. If a name string is used, then name translation would be required for proper ACL resolution. When using NFSv4.1 ACLs, enabling “Allow local NFS users with LDAP” may cause incorrect NFSv4.1 ACL behavior depending on the ACL configuration.
-
-### NFS (v3 and v4.1) with NTFS security style volumes in dual protocol configurations: 
-UNIX security style volumes leverage UNIX style permissions (mode bits and NFSv4.1 ACLs). For those types of volumes, NFS leverages only UNIX-style authentication leveraging a numeric ID or a name string, depending on the scenarios listed above. NTFS security style volumes, however, use NTFS style permissions. These permissions are assigned using Windows users and groups. When an NFS user attempts to access a volume with an NTFS style permission, a UNIX to Windows name mapping must occur to ensure proper access controls. In this scenario, the NFS numeric ID is still passed to the Azure NetApp Files NFS volume, but there is a requirement for the numeric ID to be translated to a UNIX user name so that it can then be mapped to a Windows user name for initial authentication. For instance, if numeric ID 1001 attempts to access an NFS mount with NTFS security style permissions that allow access to Windows user “user1,” then 1001 would need to be resolved in LDAP to the “user1” user name to gain expected access. If no user with the numeric ID of “1001” exists in LDAP, or if LDAP is misconfigured, then the UNIX to Windows name mapping that is attempted will be [email protected]. In most cases, users with that name do not exist, so authentication fails and access is denied. Similarly, if the numeric ID 1001 resolves to the wrong user name (such as user2) then the NFS request will map to an unexpected Windows user and the permissions for the user will use the “user2” access controls.
-
-Enabling “Allow local NFS users with LDAP” will disable all LDAP translations of numeric IDs to user names, which will effectively break access to NTFS security style volumes. As such, use of this option with NTFS security style volumes is highly discouraged.
-
-
-
 ## Custom name mapping using LDAP
 
 LDAP can be a name mapping resource, if the LDAP schema attributes on the LDAP server have been populated. For example, to map UNIX users to corresponding Windows user names that don't match one-to-one (that is, *asymmetric*), you can specify a different value for `uid` in the user object than what is configured for the Windows user name.
@@ -175,6 +149,29 @@ drwxrwxrwx  2 root     root   4096 Jul  3 20:09 .
 drwxr-xr-x 21 root     root   4096 Jul  3 20:12 ..
 -rwxrwxrwx  1 UNIXuser group1   19 Jul  3 20:10 asymmetric-user-file.txt
 ```
+## Allow local NFS users with LDAP
+
+When a user attempts to access an Azure NetApp Files volume via NFS, the request comes in a numeric ID. By default, Azure NetApp Files supports extended group memberships for NFS users (to go beyond the standard 16 group limit). As a result, Azure NetApp files will attempt to take that numeric ID and look it up in LDAP in an attempt to resolve the group memberships for the user rather than passing the group memberships in an RPC packet. Due to this behavior, if that numeric ID cannot be resolved to a user in LDAP, the lookup will fail and access will be denied – even if the requesting user has permission to access the volume or data structure. The Allow local NFS users with LDAP option in Active Directory connections is intended to disable those LDAP lookups for NFS requests by disabling the extended group functionality. It doesn't provide “local user creation/management” within Azure NetApp Files.
+
+When “Allow local NFS users with LDAP” option is enabled, numeric IDs are passed to Azure NetApp Files and no LDAP lookup is performed. This creates varying behavior for different scenarios, as covered below.
+
+### NFSv3 with UNIX security style volumes
+
+Numeric IDs don't need to be translated to user names. The “Allow local NFS users with LDAP” option will not impact access to the volume but may impact how user/group ownership (name translation) is displayed on the NFS client. For instance, if a numeric ID of 1001 is user1 in LDAP, but is user2 on the NFS client’s local passwd file, the client will display “user2” as the owner of the file when the numeric ID is 1001.
+
+### NFSv4.1 with UNIX security style volumes:
+Numeric IDs don't need to be translated to user names. By default, NFSv4.1 uses name strings ([email protected]) for its authentication. However, Azure NetApp Files supports the use of numeric IDs with NFSV4.1, which means that NFSv4.1 requests will arrive to the NFS server with a numeric ID. If no numeric ID to user name translation exists in local files or name services like LDAP for the Azure NetApp Files volume, then the numeric is presented to the client. If a numeric ID translates to a user name, then the name string will be used. If the name string doesn't match, the client will squash the name to the anonymous user specified in the client’s idmapd.conf file. Enabling the “Allow local NFS users with LDAP” option will not impact NFSv4.1 access, as it will fall back to standard NFSv3 behavior unless Azure NetApp Files can resolve a numeric ID to a user name in its local NFS user database. Azure NetApp Files has a set of default UNIX users that can be problematic for some clients and squash to a “nobody” user if domain ID strings do not match.
+* Local users include: root (0), pcuser (65534), nobody (65535).
+* Local groups include: root (0), daemon (1), pcuser (65534), nobody (65535).
+  
+Most commonly, root may show incorrectly in NFSv4.1 client mounts when the NFSv4.1 domain ID is misconfigured. For more information on the NFSv4.1 ID domain, see [Configuring NFSv4.1 ID domain for Azure NetApp Files](https://www.youtube.com/watch?v=UfaJTYWSVAY). 
+
+NFSv4.1 ACLs can be configured using either a name string or a numeric ID. If numeric IDs are used, no name translation is required. If a name string is used, then name translation would be required for proper ACL resolution. When using NFSv4.1 ACLs, enabling “Allow local NFS users with LDAP” may cause incorrect NFSv4.1 ACL behavior depending on the ACL configuration.
+
+### NFS (v3 and v4.1) with NTFS security style volumes in dual protocol configurations: 
+UNIX security style volumes leverage UNIX style permissions (mode bits and NFSv4.1 ACLs). For those types of volumes, NFS leverages only UNIX-style authentication leveraging a numeric ID or a name string, depending on the scenarios listed above. NTFS security style volumes, however, use NTFS style permissions. These permissions are assigned using Windows users and groups. When an NFS user attempts to access a volume with an NTFS style permission, a UNIX to Windows name mapping must occur to ensure proper access controls. In this scenario, the NFS numeric ID is still passed to the Azure NetApp Files NFS volume, but there is a requirement for the numeric ID to be translated to a UNIX user name so that it can then be mapped to a Windows user name for initial authentication. For instance, if numeric ID 1001 attempts to access an NFS mount with NTFS security style permissions that allow access to Windows user “user1,” then 1001 would need to be resolved in LDAP to the “user1” user name to gain expected access. If no user with the numeric ID of “1001” exists in LDAP, or if LDAP is misconfigured, then the UNIX to Windows name mapping that is attempted will be [email protected]. In most cases, users with that name do not exist, so authentication fails and access is denied. Similarly, if the numeric ID 1001 resolves to the wrong user name (such as user2) then the NFS request will map to an unexpected Windows user and the permissions for the user will use the “user2” access controls.
+
+Enabling “Allow local NFS users with LDAP” will disable all LDAP translations of numeric IDs to user names, which will effectively break access to NTFS security style volumes. As such, use of this option with NTFS security style volumes is highly discouraged.
 
 ## LDAP schemas