acrolinx

b-ahibbard · b-ahibbard · commit 06276c2f06c9 · 2025-02-18T22:12:02.000-05:00
diff --git a/articles/azure-netapp-files/lightweight-directory-access-protocol-local-users.md b/articles/azure-netapp-files/lightweight-directory-access-protocol-local-users.md
@@ -11,7 +11,7 @@ ms.author: anfdocs
 
 # Understand the allow local NFS users with LDAP option Understand name mapping using LDAP in Azure NetApp Files
 
-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 attempts to take that numeric ID and look it up in [lightweight directory access protocol (LDAP)](lightweight-directory-access-protocolmd) 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 fails and access is denied. This denial occurs even if the requesting user has permission to access the volume or data structure.
+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 attempts to take that numeric ID and look it up in [lightweight directory access protocol (LDAP)](lightweight-directory-access-protocol.md) 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 fails and access is denied. This denial occurs 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.
 
diff --git a/articles/azure-netapp-files/lightweight-directory-access-protocol-name-mapping.md b/articles/azure-netapp-files/lightweight-directory-access-protocol-name-mapping.md
@@ -11,7 +11,7 @@ ms.author: anfdocs
 
 # Understand name mapping using LDAP in Azure NetApp Files
 
-Name mapping rules with [lightweight directory access protocol (LDAP)](lightweight-directory-access-protocolmd) can be broken down into two main types: *symmetric* and *asymmetric*.
+Name mapping rules with [lightweight directory access protocol (LDAP)](lightweight-directory-access-protocol.md) can be broken down into two main types: *symmetric* and *asymmetric*.
 
 * *Symmetric* name mapping is implicit name mapping between UNIX and Windows users who use the same user name. For example, Windows user `CONTOSO\user1` maps to UNIX user `user1`.  
 * *Asymmetric* name mapping is name mapping between UNIX and Windows users who use **different** user names. For example, Windows user `CONTOSO\user1` maps to UNIX user `user2`.
diff --git a/articles/azure-netapp-files/lightweight-directory-access-protocol-schemas.md b/articles/azure-netapp-files/lightweight-directory-access-protocol-schemas.md
@@ -1,6 +1,6 @@
 ---
 title: Understand LDAP schemas in Azure NetApp Files
-description: This article helps you understand the allow local NFS users option in the lightweight directory access protocol (LDAP).
+description: This article helps you understand schemas in the lightweight directory access protocol (LDAP).
 services: azure-netapp-files
 author: whyistheinternetbroken
 ms.service: azure-netapp-files
@@ -13,7 +13,7 @@ ms.author: anfdocs
 
 [Lightweight directory access protocol (LDAP)](lightweight-directory-access-protocol.md) schemas are how LDAP servers organize and collect information. LDAP server schemas generally follow the same standards, but different LDAP server providers might have variations on how schemas are presented. 
 
-When Azure NetApp Files queries LDAP, schemas are used to help speed up name lookups because they enable the use of specific attributes to find information about a user, such as the UID. The schema attributes must exist in the LDAP server for Azure NetApp Files to be able to find the entry. Otherwise, LDAP queries might return no data and authentication requests might fail.
+When Azure NetApp Files queries LDAP, schemas are used to help accelerate name lookups because they enable the use of specific attributes to find information about a user, such as the UID. The schema attributes must exist in the LDAP server for Azure NetApp Files to be able to find the entry. Otherwise, LDAP queries might return no data and authentication requests might fail.
 
 For example, if a UID number (such as root=0) must be queried by Azure NetApp Files, then the schema attribute RFC 2307 `uidNumber Attribute` is used. If no UID number `0` exists in LDAP in the `uidNumber` field, then the lookup request fails.
 
@@ -23,8 +23,7 @@ The schema type currently used by Azure NetApp Files is a form of schema based o
 
 This RFC extension fits nicely into how Microsoft Active Directory manages users and groups through the usual management tools. This is because when you add a Windows user to a group (and if that group has a valid numeric GID) using the standard Windows management methods, LDAP lookups will pull the necessary supplemental group information from the usual Windows attribute and find the numeric GIDs automatically.
 
-
-When Azure NetApp Files volumes need to perform LDAP lookups for NFS user identities, a series of attributes defined by an LDAP schema based on RFC-2307bis. The following table shows the attributes used by LDAP lookups, which are the defaults defined in Microsoft Active Directory when UNIX attributes are leveraged. For proper functionality, ensure these attributes are properly populated on user and group accounts in LDAP.
+When Azure NetApp Files volumes need to perform LDAP lookups for NFS user identities, a series of attributes defined by an LDAP schema based on RFC-2307bis. The following table shows the attributes used by LDAP lookups, which are the defaults defined in Microsoft Active Directory when UNIX attributes are used. For proper functionality, ensure these attributes are properly populated on user and group accounts in LDAP.
 
 | UNIX attribute | LDAP Schema Value | 
 | - | - |
@@ -43,13 +42,17 @@ When Azure NetApp Files volumes need to perform LDAP lookups for NFS user identi
 | UNIX member UID | memberUid*** |
 | UNIX group of unique names object class| Group** |
 
+
 \* Required attribute for proper LDAP functionality
+
 \** Populated in Active Directory by default
+
 \*** Not required
 
 ## Understand LDAP attribute indexing
 
-Active Directory LDAP provides an [indexing method for attributes](/windows/win32/adschema/attributes-indexed) that helps speed up lookup requests. This is particularly useful in large directory environments, where an LDAP search can potentially exceed the 10 second timeout value for lookups in Azure NetApp Files. If a search timeout is exceeded, the LDAP lookup will fail and access will not work properly, since the service cannot verify the user or group identity requesting access.
+Active Directory LDAP provides an [indexing method for attributes](/windows/win32/adschema/attributes-indexed) that helps speed up lookup requests. This is particularly useful in large directory environments, where an LDAP search can potentially exceed the 10-second time-out value for lookups in Azure NetApp Files. If a search exceeds its time-out value, the LDAP lookup fails, and access won't work properly because the service cannot verify the user or group identity requesting access.
+
 By default, Microsoft Active Directory LDAP will index the following UNIX attributes used by Azure NetApp Files for LDAP lookups:
 
 - [Common Name (CN)](/windows/win32/adschema/a-cn)
@@ -68,7 +71,7 @@ Attributes are indexed via [the `searchFlags` value](/openspecs/windows_protocol
 
 :::image type="content" source="./media/lightweight-directory-access-protocol-schemas/connection-settings.png" alt-text="Screenshot of connection settings menu." lightbox="./media/lightweight-directory-access-protocol-schemas/connection-settings.png":::
 
-By default, the uid attribute object’s `searchFlags` are set to 0x8 (PRESERVE_ON_DELETE). This default setting esnures that even if the object in Active Directory is deleted, the attribute value remains stored in the directory as a historical record of the user’s attribute.
+By default, the uid attribute object’s `searchFlags` are set to 0x8 (PRESERVE_ON_DELETE). This default setting ensures that even if the object in Active Directory is deleted, the attribute value remains stored in the directory as a historical record of the user’s attribute.
 
 :::image type="content" source="./media/lightweight-directory-access-protocol-schemas/search-flag-no-index.png" alt-text="Screenshot of uid properties menu." lightbox="./media/lightweight-directory-access-protocol-schemas/search-flag-no-index.png":::
 
@@ -78,7 +81,7 @@ In comparison, an attribute that is indexed in Active Directory for LDAP searche
 
 Because of this, queries for uidNumber return faster than queries for uid. For consistency and performance, you can adjust the `searchFlags` value for uid to 9 by adding 0x1 along with the existing value of 0x8, which is (INDEX | PRESERVE_ON_DELETE). This addition maintains the default behavior while adding attribute indexing to the directory.
 
-:::image type="content" source="./media/lightweight-directory-access-protocol-schemas/integer-attribute-editor.png" alt-text="Screenshot of integer attribute editor." lightbox="./media/lightweight-directory-access-protocol-schemas/integer-attribute-editor.png.png":::
+:::image type="content" source="./media/lightweight-directory-access-protocol-schemas/integer-attribute-editor.png" alt-text="Screenshot of integer attribute editor." lightbox="./media/lightweight-directory-access-protocol-schemas/integer-attribute-editor.png":::
 
 :::image type="content" source="./media/lightweight-directory-access-protocol-schemas/search-flag-indexed.png" alt-text="Screenshot of uid properties menu with indexing added." lightbox="./media/lightweight-directory-access-protocol-schemas/search-flag-indexed.png":::
 
diff --git a/articles/azure-netapp-files/lightweight-directory-access-protocol.md b/articles/azure-netapp-files/lightweight-directory-access-protocol.md
@@ -57,13 +57,13 @@ LDAP offers various benefits for your UNIX users and groups as an identity sourc
 The following section discusses the basics of LDAP as it pertains to Azure NetApp Files.
 
 * LDAP information is stored in flat files in an LDAP server and is organized by way of an LDAP schema. You should configure LDAP clients in a way that coordinates their requests and lookups with the schema on the LDAP server.
-* LDAP clients initiate queries by way of an LDAP bind, which is essentially a login to the LDAP server using an account that has read access to the LDAP schema. The LDAP bind configuration on the clients is configured to use the security mechanism that is defined by the LDAP server. Sometimes, they are user name and password exchanges in plain text (simple). In other cases, binds are secured through Simple Authentication and Security Layer methods (`sasl`) such as Kerberos or LDAP over TLS. Azure NetApp Files uses the SMB machine account to bind using SASL authentication for the best possible security.
+* LDAP clients initiate queries by way of an LDAP bind, which is essentially a login to the LDAP server using an account that has read access to the LDAP schema. The LDAP bind configuration on the clients is configured to use the security mechanism that is defined by the LDAP server. Sometimes, they're user name and password exchanges in plain text (simple). In other cases, binds are secured through Simple Authentication and Security Layer methods (`sasl`) such as Kerberos or LDAP over TLS. Azure NetApp Files uses the SMB machine account to bind using SASL authentication for the best possible security.
 * User and group information that is stored in LDAP is queried by clients by using standard LDAP search requests as defined in [RFC 2307](https://datatracker.ietf.org/doc/html/rfc2307). In addition, newer mechanisms, such as [RFC 2307bis](https://datatracker.ietf.org/doc/html/draft-howard-rfc2307bis-02), allow more streamlined user and group lookups. Azure NetApp Files uses a form of RFC 2307bis for its schema lookups in Windows Active Directory. 
 * LDAP servers can store user and group information and netgroup. However, Azure NetApp Files currently can't use netgroup functionality in LDAP on Windows Active Directory.
 * LDAP in Azure NetApp Files operates on port 389. This port currently can't be modified to use a custom port, such as port 636 (LDAP over SSL) or port 3268 (Active Directory Global Catalog searches).
 * Encrypted LDAP communications can be achieved using [LDAP over TLS](configure-ldap-over-tls.md#considerations) (which operates over port 389) or LDAP signing, both of which can be configured on the Active Directory connection.
-* Azure NetApp Files supports LDAP queries that take no longer than 3 seconds to complete. If the LDAP server has many objects, that timeout may be exceeded, and authentication requests can fail. In those cases, consider specifying an [LDAP search scope](https://ldap.com/the-ldap-search-operation/) to filter queries for better performance.
-* Azure NetApp Files also supports specifying preferred LDAP servers to help speed up requests. Use this setting if you want to ensure the LDAP server closest to your Azure NetApp Files region is being used.
+* Azure NetApp Files supports LDAP queries that take no longer than 3 seconds to complete. If the LDAP server has many objects, that time out might be exceeded, and authentication requests can fail. In those cases, consider specifying an [LDAP search scope](https://ldap.com/the-ldap-search-operation/) to filter queries for better performance.
+* Azure NetApp Files also supports specifying preferred LDAP servers to help accelerate requests. Use this setting if you want to ensure the LDAP server closest to your Azure NetApp Files region is being used.
 * If no preferred LDAP server is set, the Active Directory domain name is queried in DNS for LDAP service records to populate the list of LDAP servers available for your region located within that SRV record. You can manually query LDAP service records in DNS from a client using [`nslookup`](/troubleshoot/windows-server/networking/verify-srv-dns-records-have-been-created) or [`dig`](https://www.cyberciti.biz/faq/linux-unix-dig-command-examples-usage-syntax/) commands. 
 
     For example: 
@@ -111,9 +111,9 @@ The following section discusses the basics of LDAP as it pertains to Azure NetAp
     contoso.com      internet address = y.y.y.y
     ```
 * LDAP servers can also be used to perform custom name mapping for users. For more information, see [Understand name mapping using LDAP](lightweight-directory-access-protocol-name-mapping.md). 
-* LDAP query timeouts 
+* LDAP query time outs 
 
-    By default, LDAP queries time out if they can't completed in a timely fashion. If an LDAP query fails due to a timeout, the user and/or group lookup fails, and access to the Azure NetApp Files volume may be denied, depending on the permission settings of the volume. Refer to [Create and manage Active Directory connections](create-active-directory-connections.md#ldap-query-timeouts) to understand Azure NetApp Files LDAP query timeout settings.
+    By default, LDAP queries time out if they can't completed in a timely fashion. If an LDAP query fails due to a time out, the user and/or group lookup fails, and access to the Azure NetApp Files volume may be denied, depending on the permission settings of the volume. Refer to [Create and manage Active Directory connections](create-active-directory-connections.md#ldap-query-timeouts) to understand Azure NetApp Files LDAP query time out settings.
 
 ## Next steps 
 
