acrolinx

Author: b-ahibbard

articles/azure-netapp-files/domain-name-system-concept.md

@@ -10,7 +10,7 @@ ms.author: anfdocs
 ---
 # Understand Domain Name Systems in Azure NetApp Files 
 
-Azure NetApp Files supports the use of Active Directory integrated DNS or standalone DNS servers and requires reliable access to Domain Name System (DNS) services and up-to-date DNS records. Poor network connectivity between Azure NetApp Files and DNS servers can cause client access interruptions or client time outs. Incomplete or incorrect DNS records for Active Directory Domain Services (AD DS) or Azure NetApp Files can cause client access interruptions or client time outs. 
+Azure NetApp Files supports the use of Active Directory integrated DNS or standalone DNS servers and requires reliable access to Domain Name System (DNS) services and up-to-date DNS records. Poor network connectivity between Azure NetApp Files and DNS servers can cause client access interruptions or client time-outs. Incomplete or incorrect DNS records for Active Directory Domain Services (AD DS) or Azure NetApp Files can cause client access interruptions or client time-outs. 
 
 The DNS service is a critical component of data access in Azure NetApp Files. File protocol access over SMB, NFSV4.1 Kerberos, LDAP, and Active Directory Site Discovery all make significant use of DNS for their operations. Using a hostname centrally located in DNS simplifies access to a volume and protects against scenarios when an IP address changes. Rather than an administrator needing to inform users of a new IP address, users can continue using the user-friendly hostname.
 
@@ -31,7 +31,7 @@ In some cases, external DNS servers (such as BIND) may be used in lieu of (or in
 
 :::image type="content" source="media/domain-name-system-concept/external-bind-dns.png" alt-text="Diagram of external bind configuration." lightbox="media/domain-name-system-concept/external-bind-dns.png":::
 
-Azure NetApp Files supports the use of both integrated and external DNS servers, but when using external DNS servers without Active Directory integration, it's important to ensure that the necessary service (SRV) records are added to DNS for proper functionality and redundancy of services. Poor network connectivity between Azure NetApp Files and DNS servers can cause client access interruptions or client time outs. Incomplete or incorrect DNS records for AD DS or Azure NetApp Files can cause client access interruptions or client time outs.
+Azure NetApp Files supports the use of both integrated and external DNS servers, but when using external DNS servers without Active Directory integration, it's important to ensure that the necessary service (SRV) records are added to DNS for proper functionality and redundancy of services. Poor network connectivity between Azure NetApp Files and DNS servers can cause client access interruptions or client time-outs. Incomplete or incorrect DNS records for AD DS or Azure NetApp Files can cause client access interruptions or client time-outs.
 
 See [DNS records in Azure NetApp Files](#types-of-dns-records-in-azure-netapp-files) for a list of SRV records the service uses. Also review the [guidelines for DNS with Active Directory](/windows-server/) and [Integrating AD DS into an existing DNS infrastructure](/windows-server/identity/ad-ds/plan/integrating-ad-ds-into-an-existing-dns-infrastructure).
 
@@ -321,9 +321,9 @@ When secure DNS is enabled, Azure NetApp Files negotiates with the DNS server to
 
 To reduce load on DNS servers, DNS clients make use of caching concepts to store previous queries in memory so that repeat requests for a hostname, IP or service are kept locally for the period of time defined by the DNS record’s TTL.
 
-Azure NetApp Files makes use of DNS caches like any other standard DNS client. When the service requests a DNS record, that record has a TTL defined. By default, Active Directory DNS entries have a TTL of 600 seconds (10 minutes) unless specified otherwise. If a DNS record is updated and lives in the Azure NetApp Files cache and the TTL is 10 minutes, then the new record doesn't update in Azure NetApp Files until the cache is purged after the time out value. There's currently no way to manually purge this cache. If a lower TTL is desired, make the change from the DNS server.
+Azure NetApp Files makes use of DNS caches like any other standard DNS client. When the service requests a DNS record, that record has a TTL defined. By default, Active Directory DNS entries have a TTL of 600 seconds (10 minutes) unless specified otherwise. If a DNS record is updated and lives in the Azure NetApp Files cache and the TTL is 10 minutes, then the new record doesn't update in Azure NetApp Files until the cache is purged after the time-out value. There's currently no way to manually purge this cache. If a lower TTL is desired, make the change from the DNS server.
 
-When using external DNS servers (such as BIND), the default time out values can differ. If undefined, a BIND DNS record's TTL is 604,800 seconds (seven days), too long for effective DNS caching. As such, when creating DNS records manually, it is important to manually set the TTL for the record to a reasonable value. Using the Microsoft default of 10 minutes is recommended for a blend of performance and reliability for DNS lookups.
+When using external DNS servers (such as BIND), the default time-out values can differ. If undefined, a BIND DNS record's TTL is 604,800 seconds (seven days), too long for effective DNS caching. As such, when creating DNS records manually, it is important to manually set the TTL for the record to a reasonable value. Using the Microsoft default of 10 minutes is recommended for a blend of performance and reliability for DNS lookups.
 
 You can manually query a DNS record's TTL using `nslookup` or `dig` commands. For examples, see [Using `nslookup` and `dig` for DNS queries](#using-nslookup-and-dig-for-dns-queries).
 

articles/azure-netapp-files/kerberos.md

@@ -60,7 +60,7 @@ This section defines key terminology that is used when describing Kerberos proce
 | -- | ------ |
 | Key distribution center (KDC)	| The KDC is the authentication server that includes the ticket-granting service (TGS) and the authentication service (AS). The terms KDC, AS, and TGS are used interchangeably. In Microsoft environments, an Active Directory domain controller is a KDC. |
 | Realm (or Kerberos realm) | A realm (or Kerberos realm) can use any ASCII string. The standard is to use the domain name in uppercase; for example, contoso.com becomes the realm CONTOSO.COM. Kerberos realms usually are configured in krb5.conf files on clients and servers. <br></br> Administratively, each principal@REALM must be unique. To avoid a single point of failure, each realm can have multiple KDCs that share the same database (principals and their passwords) and have the same KDC master keys. Microsoft Windows Active Directory does this natively by way of Active Directory replication, which takes place every 15 minutes by default.
-| Principal	| The term principal refers to every entity within a Kerberos database. Users, computers, and services are all assigned principals for Kerberos authentication. Every principal must be unique within the Kerberos database and is defined by its distinguished name. A principal can be a user principal name (UPN) or a service principal name (SPN). <br></br> A principal name has three parts: <ul><li>**Primary** - The primary part can be a user or a service such as the NFS service. It can also be the special service “host,” which signifies that this service principal is set up to provide multiple various network services.</li><li>**Instance** - This part is optional in the case of a user. A user can have more than one principal, but each principal must be unique in the KDC. For example, Fred might have a principal that is for everyday use ([email protected]) and a principal that allows privileged use such as a sysadmin account ([email protected]). The instance is required for service principals and designates the fully qualified domain name (FQDN) of the host that provides the service.</li><li>**Realm** - A Kerberos realm is the set of Kerberos principals that are registered within a Kerberos server. By convention, the realm name is usually the same as the DNS name, but it's converted to uppercase letters. Uppercase letters aren't obligatory, but the convention provides easy distinction between the DNS name and the realm name.</li></ul> <!-- image --> |
+| Principal	| The term principal refers to every entity within a Kerberos database. Users, computers, and services are all assigned principals for Kerberos authentication. Every principal must be unique within the Kerberos database and is defined by it's distinguished name. A principal can be a user principal name (UPN) or a service principal name (SPN). <br></br> A principal name has three parts: <ul><li>**Primary** - The primary part can be a user or a service such as the NFS service. It can also be the special service "host," which signifies that this service principal is set up to provide multiple various network services.</li><li>**Instance** - This part is optional in the case of a user. A user can have more than one principal, but each principal must be unique in the KDC. For example, Fred might have a principal that is for everyday use ([email protected]) and a principal that allows privileged use such as a sysadmin account ([email protected]). The instance is required for service principals and designates the fully qualified domain name (FQDN) of the host that provides the service.</li><li>**Realm** - A Kerberos realm is the set of Kerberos principals that are registered within a Kerberos server. By convention, the realm name is usually the same as the DNS name, but it's converted to uppercase letters. Uppercase letters aren't obligatory, but the convention provides easy distinction between the DNS name and the realm name.</li></ul> <!-- image --> |
 | Tickets | A ticket is a temporary set of credentials that verifies the identity of a principal for a service and contains the session key. A ticket can be a service, an application ticket, or a ticket-granting ticket (TGT). Tickets are exchanged between client, server, and KDC for Kerberos authentication. |
 | Secret keys | Kerberos uses a symmetric key system in which the secret key is used for both encryption and decryption. The secret key is generated from the principal’s Kerberos password with a one-way hash function. The KDC stores the password for each principal and can thus generate the principal’s secret key. For users who request a Kerberos service, the secret key is typically derived from a password presented to the kinit program. Service and daemon principals typically don’t use a password; instead, the result of the one-way hash function is stored in a keytab. |
 | Keytab | A keytab contains a list of principals and their secret keys. The secret keys in a keytab are often created by using a random password and are used mostly for service or daemon principals. |
@@ -224,7 +224,7 @@ In most cases, knowing detailed steps in depth isn't necessary for day-to-day ad
     - `_ldap._tcp.CONTOSO.COM`
     - `_kerberos._tcp.CONTOSO.COM` 
     >[!NOTE]
-    >These queries occur multiple times in the same call over different portions of the process. DNS issues can create slowness in these calls or, with time outs, complete failures.
+    >These queries occur multiple times in the same call over different portions of the process. DNS issues can create slowness in these calls or, with time-outs, complete failures.
         - If the queries fail to find an entry or if the entries found can't be contacted, SMB volume creation fails.
         - If the DNS queries succeed, then the next steps are processed.
 - ICMP (ping) is sent to check that the IP addresses returned from DNS are reachable. 
@@ -437,7 +437,7 @@ When the NFS Kerberos realm is configured, a local hosts entry is added in the s
 
 :::image type="content" source="media/kerberos/nfs-kerberos-configuration.png" alt-text="Diagram of Kerberos realm configuration." lightbox="media/kerberos/nfs-kerberos-configuration.png":::
 
-This local host entry acts as a "last resort" in case of a KDC outage on the KDC specified in the realm configuration and failure to query redundant KDCs via DNS. 
+This local host entry acts as a "last resort" if a KDC outage occurs on the KDC specified in the realm configuration and failure to query redundant KDCs via DNS. 
 
 >[!NOTE]
 >If the KDC in the Kerberos realm needs to be brought down for maintenance (such as for upgrades or decommissioning of a server), it's recommended to configure the realm to use a KDC that isn't undergoing maintenance to avoid outages.
@@ -470,8 +470,8 @@ The following diagram shows how an NFS SPN is created when an Azure NetApp Files
 >[!NOTE]
 >These queries occur multiple times in the same call over different portions of the process. DNS issues can create slowness in these calls or complete failures. These records don't appear to exist by default in Active Directory deployments and must be created manually.
 - If the queries fail to find an entry or if the entries found can't be contacted or used as the master KDC, then an A record query using the realm name found in the NFS Kerberos realm configuration is used as a last resort to connect to the KDC over port 88.
-- During the configuration of NFS Kerberos, a static host entry for the specified KDC is added to the local hosts file as a backup in case DNS lookups fail.
-- If there's a cached DNS entry for the realm, then it's used. If not, then the local file entry is used. Cached DNS entries live as long as the Time to Live (TTL) is configured for the DNS record. The local file entry is configured with an 86400 second TTL (24 hours). The ns-switch configuration for host lookups in Azure NetApp Files uses files first and then DNS. When the local entry is found, no more queries are performed.
+- During the configuration of NFS Kerberos, a static host entry for the specified KDC is added to the local hosts file as a backup if DNS lookups fail.
+- If there's a cached DNS entry for the realm, then it's used. If not, then the local file entry is used. Cached DNS entries live as long as the Time to Live (TTL) is configured for the DNS record. The local file entry is configured with an 86,400 second TTL (24 hours). The ns-switch configuration for host lookups in Azure NetApp Files uses files first and then DNS. When the local entry is found, no more queries are performed.
 - The SMB machine account created when the Active Directory connection is created is used as credentials for an Active Directory LDAP bind using SASL/GSS over port 389 to search for any existing entries of the desired SPN or machine account name. If the SPN or machine account name already exists, an error is sent. If the SPN doesn't exist in the LDAP query, then the machine account creation is performed in the designated OU with entries for the following attributes set by Azure NetApp Files:
     - cn (NFS-MACHINE)
     - sAMAcc- untName (NFS-MACHINE$)
@@ -518,7 +518,7 @@ When an Azure NetApp Files NFS Kerberos mount is accessed by a user (other than
 :::image type="content" source="media/kerberos/kerberos-user-access.png" alt-text="Diagram of NFS Kerberos mount access with user principals." lightbox="media/kerberos/kerberos-user-access.png":::
 
 <details>
-<summary>For detailed steps about how an NFS Kerberos volume is accessed with a non-root user with Azure NetApp Files, expand the list.</summary>
+<summary>For detailed steps about how an NFS Kerberos volume is accessed with a nonroot user with Azure NetApp Files, expand the list.</summary>
 
 - The user logs into the KDC either with a username/password exchange or via a keytab file to get a TGT via an AS-REQ call to use for collecting a service ticket from the Azure NetApp Files volume.
 - The export policy rule is checked to ensure that Kerberos access is allowed to the export path for the client machine

articles/azure-netapp-files/sever-message-block-support.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: whyistheinternetbroken
 ms.service: azure-netapp-files
 ms.topic: how-to
-ms.date: 01/22/2025
+ms.date: 01/29/2025
 ms.author: anfdocs
 ---
 # Understand Server Message Block support in Azure NetApp Files