Επεξεργασία

Κοινή χρήση μέσω

Understand Kerberos in Azure NetApp Files

  • Άρθρο

Kerberos is an authentication protocol that uses a secret key to validate the identity of principals. Secret keys are generated by taking a principal's password and converting it into a hashed cryptographic key format using an agreed upon encryption method by the client and server (such as AES). See the Kerberos terminology section to learn about the terms used in this document.

Key Distribution Centers (KDCs) such as Windows Active Directory maintain a database of Kerberos principals and their hashed passwords. In Kerberos, the secret key is proof of a unique identity. Therefore, the KDC can be trusted to authenticate any principal to any other principal such as authenticating an NFS client Service Principal Name (SPN) to an NFS server SPN at mount. It can also be trusted to authenticate a user principal to an NFS server SPN for user access to a NAS mount point. As an added security measure, Kerberos doesn't send cleartext passwords for authentication across the wire.

Azure NetApp Files supports the use of Kerberos to provide in-flight security for both the SMB and NFS protocols.

Supported encryption types

Azure NetApp Files supports NFS Kerberos with specific encryption types, depending on the operating mode and the version that you use.

To ensure that a client uses the appropriate encryption type, you can limit the valid encryption types on the object principal located on the KDC (for example, the machine account) or in the client’s manual created keytab file rather than globally in the /etc/krb5.conf file, if possible, since management of numerous client krb5.conf files can be a management headache. Centrally managing Kerberos from the KDC is more scalable in large enterprise environments, is easier to automate, and forces the client to use stronger encryption types when they're supported.

Note

It's recommended to set the option allow_weak_crypto to false in the krb5.conf file on clients. This setting prevents less secure enctypes for Kerberos communication (such as DES or 3DES).

The following table shows the supported encryption types for Kerberos (both SMB and NFS) for Azure NetApp Files.

Protocol Supported encryption types
SMB
  • RC4-HMAC
  • AES-128
  • AES-256
NFS AES-256

Supported NFS Kerberos security modes

In addition to the concept of encryption types, there are also levels of security and integrity checking in Kerberos. Depending on the security mode in use, these security modes help prevent man-in-the-middle attacks by offering end-to-end encryption for NFS traffic.

In Azure NetApp Files, these security modes are specified on the export policy rules set for the volume for NFS and defined during the initial NFS mount via the sec mount option.

For instance: # mount -o sec=krb5p

Note

For SMB Kerberos, security modes for Kerberos are controlled via SMB encryption settings on the share, UNC hardening, and SMB signing/sealing policies on the domain controllers.

The following security modes are supported by Azure NetApp Files for use with NFS Kerberos:

Security mode Description
krb5 Authentication encryption only.

Uses Kerberos V5 name strings and user principal names instead of local UNIX user IDs (UIDs) and group IDs (GIDs) to authenticate users.
krb5i Authentication encryption and encrypted integrity checking.

Uses Kerberos V5 for user authentication and also performs integrity checking of NFS operations by using secure checksums to prevent data tampering and man-in-the-middle attacks.
krb5p Entire NFS conversation encrypted.

Uses Kerberos V5 for user authentication and integrity checking and also encrypts all NFS traffic to prevent packet sniffing. This setting is the most secure, but it also creates the most performance overhead.

Kerberos terminology

This section defines key terminology that is used when describing Kerberos processes. This section is meant to help clarify terms that might be unfamiliar to storage administrators.

Term Definition
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.

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).

A principal name has three parts:
  • 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.
  • 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 (fred@contoso.com) and a principal that allows privileged use such as a sysadmin account (admin-fred@contoso.com). The instance is required for service principals and designates the fully qualified domain name (FQDN) of the host that provides the service.
  • 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.
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.

Network port information

The following table covers which network ports are used for Kerberos communications. If a network firewall is in place, these ports should be opened to allow proper Kerberos functionality. You can find more information about these ports at the IANA Service Name and Transport Protocol Port Number Registry.

Service Port
Kerberos 88 (TCP/UDP)
kpasswd 464 (TCP/UDP)
Lightweight directory access protocol (LDAP) (for name mappings) 389 (TCP/UDP)
Admin server 749 (TCP/UDP)
Global catalog (Windows user lookups) 3268 (TCP/UDP)

Cache age values in Azure NetApp Files

The following table displays the amount of time a cache entry lives in an Azure NetApp Files volume.

Cache Cache age
Idle name server connections 60 seconds
LDAP query time out 10 seconds
Local DNS host entry for KDC TTL 24 hours
Kerberos ticket age Specified by KDC* and/or client

*Defaults to 10 hours for Windows Active Directory KDCs
User credentials 24 hours
Kerberos time skew 5 minutes

Requirements for properly functioning Kerberos environments in Azure NetApp Files

Kerberos authentication is highly dependent on external services for proper functionality. In Microsoft Active Directory, most of those services are combined into a single server in many cases. For instance, an Active Directory domain controller can service the following Kerberos dependencies:

  • Time synchronization services
  • DNS
  • Kerberos key distribution
  • Password services/single sign-on
  • Identity services (such as LDAP)

When using native Microsoft Active Directory (the only KDC type that Azure NetApp Files currently supports), then most of the external dependencies for Kerberos in Azure NetApp Files are covered, such as DNS, KDC, and password services. In some cases, required services may be hosted outside of the Active Directory domain (such as DNS). In those cases, it's important to ensure the required services are configured properly.

Azure NetApp Files has specific dependencies for properly functioning NFS Kerberos. Continue reading for more information.

Time synchronization services

Time synchronization services are mandatory when using Kerberos for authentication, as the Kerberos ticket mechanisms depend on time skews between client and server being within a default 5-minute range. If the time settings on client or server exceed that five-minute range, Kerberos authentication fails with a time skew error (KRB_AP_ERR_SKEW) and access is denied to the NAS share. This time out is a security feature that helps prevent "replay attacks," where an attacker can intercept messages between the KDC and client and then replay those messages at a later time to impersonate an authenticated user. Time skew limits help minimize the risk of those types of attacks.

Key considerations for time sync issues:

For more information, see Maximum tolerance for computer clock synchronization

Domain Name Systems (DNS)

Domain Name Systems (DNS) are mandatory for Kerberos as a security feature. Hostname resolution is used to formulate the Kerberos service principals used for authentication. In this process, forward lookups for hostnames (A/AAAA records) are used to connect to shares that leverage Kerberos authentication. That forward lookup is then used to formulate the Service Principal Name (SPN) used in the Kerberos authentication request. If an existing SPN can't be found in the KDC, then Kerberos authentication fails.

In Windows SMB environments, a backup authentication method may be tried (such as NTLM). However, in many cases, NTLM is disabled for security reasons, which would cause an access failure to the share when Kerberos authentication fails. The Windows event viewer often logs the root cause of the failures (such as duplicate/missing SPNs, DNS lookup failures, NTLM failures, etc.).

In addition to SPN resolution, DNS is heavily utilized to resolve hostnames and IP addresses for domain services, such as LDAP, Kerberos KDCs, etc. via SRV records. For more detailed information on DNS in Azure NetApp Files (including what SRV records are required), see About DNS in Azure NetApp Files.

Note

If an IP address is used for Kerberos access, the behavior depends on the NAS protocol (NFS or SMB) in use. For more information, see IP addresses for access with Kerberos.

LDAP

The Lightweight Directory Access Protocol (LDAP) leverages backend identity databases to provide a unified name service source for NAS clients and servers so that all participating devices agree on user authenticity, group memberships, and numeric IDs, which are then used for file permissions.

For Kerberos, user and service principals are stored with the entries in the LDAP databases as attributes on the principal accounts. Windows Active Directory supports this by default. In some cases (such as when creating aliases or service principals), users, and computers require the addition or modification of service principal names. You can satisfy this requirement using the Active Directory Users and Computers Microsoft Management Console (MMC) or with PowerShell. For more information on managing service principal names, see Managing service principal names.

In addition to service principal names and numeric IDs for Kerberos authentication, LDAP can also be used for UNIX user and group identities, which are used for name mapping of identities in Azure NetApp Files, as well as initial authentication for NFS Kerberos mounts via an SPN -> UNIX user name mapping. For more details, see How NFS Kerberos works in Azure NetApp Files and LDAP's role with Kerberos in Azure NetApp Files.

How SMB Kerberos works in Azure NetApp Files

SMB Kerberos works separately from NFS Kerberos services, as the machine accounts created for each protocol can't share keytabs because of the potential for changes to the Key Version Number (kvno) in one keytab impacting the other service. As a result of this, as well as natural differences in the NAS protocols, the workflows for SMB services for Kerberos and NFS for Kerberos differ in functionality in some areas.

Initial configuration of SMB services

SMB services in Azure NetApp Files are initially configured by setting up an Active Directory connection, which defines several critical pieces for interaction with domain services, including:

  • Primary DNS server (required)
  • Secondary DNS
  • Active Directory DNS name*
  • Active Directory site name (for DC discovery) (required)
  • SMB server prefix name
  • Organizational unit (where machine accounts should be stored in the Azure AD domain)
  • AES encryption enable/disable
  • LDAP signing enable/disable
  • LDAP configuration
  • SMB encryption to DC
  • Privileged users
  • Username/password credentials of user with OU permissions

Note

Only one Azure Active Directory (AD) connection is allowed per account. Once the Azure AD connection is created, any new Azure NetApp Files SMB volume uses the Azure AD connection configuration.

SMB Kerberos machine account

A machine account in Active Directory contains relevant information for use in authentication requests, including the Service Principal Name (SPN). When you create an SMB volume in Azure NetApp Files, the Active Directory connections configuration is used for interaction in creating a machine account to provide secure access to an SMB share via Kerberos (or NTLM, if enabled) authentication.

New machine accounts are created when an Azure NetApp Files SMB volume is provisioned on a specific backend resource in the service. The following shows different scenarios where an SMB machine account might be created or reused in Azure NetApp Files volume configurations.

Scenario Result
First new SMB volume New SMB machine account/DNS name
Subsequent SMB volumes created in short succession from first SMB volume Reused SMB machine account/DNS name (in most cases).
Subsequent SMB volumes created much later than first SMB volume The service determines if new machine account is needed. It's possible multiple machine accounts can be created, which creates multiple IP address endpoints.
First dual protocol volume New SMB machine account/DNS name
Subsequent dual protocol volumes created in short succession from first dual protocol volume Reused SMB machine account/DNS name (in most cases)
Subsequent dual protocol volumes created much later than first dual protocol volume The service determines if a new machine account is needed. It's possible multiple machine accounts can be created, which creates multiple IP address endpoints
First SMB volume created after dual protocol volume New SMB machine account/DNS name
First dual protocol volume created after SMB volume New SMB machine account/DNS name

The SMB machine account created for the Azure NetApp Files SMB (or dual protocol) volume uses a naming convention that adheres to the 15-character maximum that is enforced by Active Directory. The name uses the structure of [SMB Server prefix specified in Azure AD connection configuration]-[unique numeric identifier].

For instance, if you've configured your Azure AD connections to use the SMB server prefix "AZURE," the SMB machine account that Azure NetApp Files creates resembles "AZURE-7806." That same name is used in the UNC path for the SMB share (for example, \AZURE-7806) and is the name that dynamic DNS services use to create the A/AAAA record.

Note

Because a name like “AZURE-7806” can be hard to remember, it's beneficial to create a CNAME record as a DNS alias for Azure NetApp Files volumes. For more information, see Creating SMB server aliases.

Diagram of multiple machine accounts/DNS entries in Azure NetApp Files.

In some cases, when creating multiple SMB and/or dual protocol volumes, the configuration can end up with multiple disparate SMB machine accounts and DNS names.

If a single namespace for user access across the volumes is desired, this can present a challenge in configuration, as a single CNAME alias can only point to a single A/AAAA host record, while using multiple identical A/AAAA record aliases can result in unpredictability of data access in accessing volumes across different SMB machine accounts, as there's no guarantee that the endpoint the client selects in the DNS lookup contains the expected volume due to the round-robin nature of DNS record selection in those configurations.

To address this limitation, Azure NetApp Files volumes can participate as targets in a Microsoft Distributed File System (DFS) configuration, which can provide a way to associate multiple SMB volumes with a single namespace entry point.

Diagram of a distributed file system in Azure NetApp Files.

SMB Kerberos SPN creation workflow

The following diagram illustrates how an SMB Kerberos SPN is created when an Azure NetApp Files SMB or dual protocol volume is created. SMB SPNs are associated with SMB machine account objects in the domain. The SPN can be viewed and managed via the machine account properties using the attribute editor in the Advanced view.

Screenshot of Azure-SMB properties.

You can also view and manage properties with the setspn command.

Screenshot of `setspn` command.

This process follows the same steps as when a regular Windows client joins a domain (DNS, LDAP, Kerberos, RPC queries over named pipes).

Diagram of Kerberos machine account.

In most cases, knowing detailed steps in depth isn't necessary for day-to-day administration tasks, but is useful in troubleshooting any failures when attempting to create an SMB volume in Azure NetApp Files.

Detailed steps

For detailed steps about how an SMB machine account is created in Azure NetApp Files, expand the list.

  • DNS lookup is performed using the DNS configuration for the SRV record of a Kerberos KDC. Azure NetApp Files uses the following SRV records in its requests.

    • _kerberos._tcp.dc._msdcs.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM (if previous query returns no results)

  • DNS lookup is performed using the hostnames that are returned in the SRV query for the A/AAAA records of the KDCs.

    • An LDAP ping (LDAP bind and RootDSE query) is performed to search for available legacy NetLogon servers using the query (&(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)) with an attribute filter for NetLogon. Newer Windows domain controller versions (greater than 2008) don't have the NtVer value present.

  • A DNS query is performed by Azure NetApp Files to find the LDAP servers in the domain using the following SRV records:

    • _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. - 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.

  • If ping is blocked on the network by firewall policies, then the ICMP request fails. Instead, LDAP pings are used.

  • Another LDAP ping is performed to search for available legacy NetLogon servers using the query (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) with the attribute filter NetLogon. Newer Windows domain controller versions (greater than 2008) don't have the NtVer value present.

  • An AS-REQ authentication is sent from the Azure NetApp Files service using the username configured with the Active directory connection.

  • The DC responds with KRB5KDC_ERR_PREAUTH_REQUIRED, which is asking the service to send the password for the user securely.

  • A second AS-REQ is sent with the preauthentication data needed to authenticate with the KDC for access to proceed with machine account creation. If successful, a Ticket Granting Ticket (TGT) is sent to the service.

  • If successful, a TGS-REQ is sent by the service to request the CIFS service ticket (cifs/kdc.contoso.com) from the KDC using the TGT received in the AS-REP.

  • A new LDAP bind using the CIFS service ticket is performed. Queries are sent from Azure NetApp Files:

    • RootDSE base search for the ConfigurationNamingContext DN of the domain
    • OneLevel search of CN=partitions in the DN retrieved for the ConfigurationNamingContext using the filter (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) for the attribute NETBIOSname.
    • A base search using the filter (|(objectClass=organizationalUnit)(objectClass=container)) is performed on the OU specified in the Active Directory connections configuration. If unspecified, the default OU=Computers is used. This verifies the container exists.
    • A subtree search is performed on the base DN of the domain using the filter (sAMAccountName=ANF-XXXX$) to check if the account exists already.
      • If the account exists, it's reused.
    • If the account doesn't exist, it's created, provided the user has permissions to create and modify objects in the container using an addRequest LDAP command. The LDAP following attributes are set on the account:
    Attribute Value
    CN ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • Top
    • Person
    • OrganizationalPerson
    • User
    • Computer
    servicePrincipalName
    • HOST/ANF-XXXX
    • HOST/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    operatingSystem NetApp Release
    dnsHostName ANF-XXXX.CONTOSO.COM
    • If the addRequest fails, the volume creation fail. An addRequest can fail due to incorrect permissions on the container object.
    • If the addRequest succeeds, an LDAP search using the filter (sAMAccountName=ANF-XXXX$) is performed to retrieve the objectSid attribute.
    • An SMB2 "Negotiate protocol" conversation is performed to retrieve the supported Kerberos mechTypes from the KDC.
    • An SMB2 "Session setup" using the CIFS SPN and highest supported mechType and a "Tree connect" to IPC$ is performed.
    • An SMB2 lsarpc file is created in the IPC$ share.
    • A bind to DCERPC is performed. The lsarpc file is written then read.
    • The following LSA requests are then performed:

  • A TGS-REQ using the TGT is performed to retrieve the ticket for the kadmin/changepw SPN that's associated with the krbtgt account.

  • A KPASSWD request is made from the service to the KDC to change the machine account password.

  • An LDAP query is performed with the filter (sAMAccountName=ANF-XXXX) for the attributes distinguishedName and isCriticalSystemObject.

  • If the account's isCriticalSystemObject is false (the default), the retrieved DN is used to formulate a modifyRequest to the attribute msDs-SupportedEncryptionTypes. This value is set to 30, which equates to DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16).

  • A second "Negotiate protocol"/Kerberos ticket exchange/"Session setup"/"Tree connect" to IPC$ is performed. The SMB server’s machine account (ANF-XXXX$) serves as the Kerberos principal.

  • NetLogon, NetrServer ReqChallenge/Authenticate2 communications are completed.

  • A third "Negotiate protocol:/Kerberos ticket exchange/"Session setup"/"Tree connect" to IPC$ is performed; the SMB server’s machine account (ANF-XXXX$) is used as the Kerberos principal.

  • Both lsarpc and NetLogon connections are made as a final check of the account.

SMB share connection workflow (Kerberos)

When an Azure NetApp Files volume is mounting using Kerberos, a Kerberos ticket exchange is used during the multiple session setup requests to provide secure access to the share. In most cases, knowing detailed steps in depth isn't necessary for day-to-day administration tasks. This knowledge is useful in troubleshooting failures when attempting to access an SMB volume in Azure NetApp Files.

Diagram of SMB share connection workflow.

For steps detailing how SMB share is accessed in Azure NetApp Files, expand the list.
  • The client attempts to access an SMB share using the UNC path shown in Azure NetApp Files. By default, the UNC path would include the SMB server name (such as ANF-XXXX)
  • DNS is queried to map the hostname to an IP address
  • An initial SMB2 "Negotiate Protocol" conversation takes place
    • A request is sent from the client to discover which SMB dialects are supported by the server and includes what the requesting client supports
    • The server responds with what it supports, including:
      • Security mode (signing or not)
      • SMB version
      • Server GUID
      • Capabilities supported (DFS, leasing, large MTU, multichannel, persistent handles, directory leasing, encryption)
      • Max transaction size
      • Max read/write size
      • Security blob (Kerberos or NTLM)
  • A second SMB2 "Negotiate Protocol" conversation takes place as "preauthorization"/login
    • Request from client includes:
      • Preauthorization hash
      • Supported security modes (signing or not)
      • Capabilities supported (DFS, leasing, large MTU, multichannel, persistent handles, directory leasing, encryption)
      • Client GUID
      • Supported SMB dialects
    • If the preauthorization hash is accepted, the server responds with:
      • Security mode (signing or not)
      • Capabilities supported (DFS, leasing, large MTU, multichannel, persistent handles, directory leasing, encryption)
      • Max transaction size
      • Max read/write size
      • Security blob (Kerberos or NTLM)
      • SMB preauthorization integrity and encryption capabilities
  • If the protocol negotiation succeeds, a "Session setup" request is made.
    • Setup uses the preauthorization hash from the protocol negotiation.
    • Setup informs the SMB server what the requesting client supports, including:
      • StructureSize
      • Session binding flag
      • Security mode (Signing enabled/required)
      • Capabilities
      • Supported Kerberos encryption types
  • A "Session setup" response is sent.
    • SMB credits are granted.
    • Session ID is established.
    • Session flags are set (guest, null, encrypt).
    • Kerberos encryption type is defined.
  • A tree connect request is sent by the client for connection to the SMB share.
    • Share flags/capabilities are sent from server, along with share permissions.
  • The ioctl command FSCTL_QUERY_NETWORK_INTERFACE_INFO is sent to get the IP address of the SMB server.
  • The SMB server in Azure NetApp Files reports back with the network information, including: * IP address * Interface capability (RSS on or off) * RSS queue count * Link speed
  • A tree connect request is sent by the client for connection to the IPC$ administrative share.
    • The IPC$ share is a resource that shares the named pipes that are essential for communication between programs. The IPC$ share is used during remote administration of a computer and when viewing a computer's shared resources. You can't change the share settings, share properties, or ACLs of the IPC$ share. You also can't rename or delete the IPC$ share.
  • A DCERPC bind is done to the srvsvc file to establish a secure connection.
    • The file is written to with the previously retrieved information.
  • A Kerberos TGS-REQ is issued by the Windows client to the KDC to get a service ticket (ST) for the SMB service.
  • A NetShareGetInfo command is run by the SMB client to the server and a response is sent.
  • The SMB service ticket is retrieved from the KDC.
  • Azure NetApp Files attempts to map the Windows user requesting access to the share to a valid UNIX user.
    • A Kerberos TGS request is made using the SMB server Kerberos credentials stored with the SMB server’s keytab from initial SMB server creation to use for an LDAP server bind.
    • LDAP is searched for a UNIX user that is mapped to the SMB user requesting share access. If no UNIX user exists in LDAP, then the default UNIX user pcuser is used by Azure NetApp Files for name mapping (files/folders written in dual protocol volumes use the mapped UNIX user as the UNIX owner).
  • Another negotiate protocol/session request/tree connect is performed, this time using the SMB server’s Kerberos SPN to the Active Directory DC’s IPC$ share.
    • A named pipe is established to the share via the srvsvc.
    • A NETLOGON session is established to the share and the Windows user is authenticated.
  • If permissions allow it for the user, the share lists the files and folders contained in the volume.

Note

Azure NetApp Files adds entries to the Kerberos context cache for the client. These entries reside in the cache for the duration of the life of the Kerberos ticket (set by the KDC and controlled by the Kerberos policy.

Creating SMB server aliases

When Azure NetApp Files creates an SMB server using a naming convention of [SMB Server prefix specified in Azure AD connection configuration]-[unique numeric identifier]. (For details about the unique numeric identifier, see SMB Kerberos machine account). This formatting means SMB server names aren't constructed in a user-friendly way. For instance, a name of "SMB-7806" is harder to remember than something similar to "AZURE-FILESHARE."

Because of this behavior, administrators may want to create user-friendly alias names for Azure NetApp Files volumes. Doing this requires pointing a DNS canonical name (CNAME) to the existing DNS A/AAAA record in the server.

When a CNAME is created and used in UNC path requests (for example, \\AZURE-FILESHARE instead of \\SMB-7806), DNS redirect the CNAME request (AZURE-FILESHARE.contoso.com) to the proper A/AAAA record (SMB-7806.contoso.com), which is used in the Kerberos SPN retrieval (cifs/SMB-7806). This allows Kerberos access to the SMB share while using the aliased name.

If a DNS A/AAAA record is created (for instance, AZURE-FILESHARE.contoso.com) and attempted to be used as an alias, Kerberos requests fail. The failure is the result of the constructed SPN used to authenticate to the share (cifs/AZURE-FILESHARE) not matching what the Kerberos SPN is for the SMB server (cifs/SMB-7806). The failure can be mitigated if another SPN is created and appended to the SMB server machine account (such as cifs/AZURE-FILESHARE).

Supported SMB server capabilities in Azure NetApp Files

When the SMB "negotiate protocol" request is made, the Azure NetApp Files SMB server is queried for support of specific capabilities. The following table shows the capabilities queried and the response returned from an Azure NetApp Files SMB volume when a Session Setup/Tree connect is performed.

SMB capability Supported by Azure NetApp Files?
DFS target Yes
Leasing Yes
Large MTU Yes
SMB multi-channel Yes
SMB persistent handles Yes
Directory leasing No
SMB encryption Yes (if enabled)

Supported SMB share capabilities and properties in Azure NetApp Files

During SMB share access, a "tree connect" request is performed and the supported SMB share capabilities and properties are queried by the client to the Azure NetApp Files server. The following table shows the share capabilities queried and the response returned from an Azure NetApp Files SMB volume as seen in a packet capture.

SMB share capability Supported by Azure NetApp Files?
Continuously available (CA) Yes, for specific workloads* (if enabled)
Scaleout No
Cluster No
Asymmetric No
Redirect to owner No

* See Enable continuous availability on existing SMB volumes for supported workloads.

The following table displays the share properties queried and the response returned from an Azure NetApp Files SMB volume.

SMB share capability Supported by Azure NetApp Files?
DFS target Yes
DFS root No
Restrict exclusive opens No
Forced shared delete No
Allow namespace caching No
Access based enumeration Yes (if enabled)
Force level II oplock No
Enable hash V1 No
Enable hash v2 No
Encryption required Yes (if enabled)
Identity remoting No
Compressed I/O No
Isolated transport No

How NFS Kerberos works in Azure NetApp Files

NFS Kerberos works separately from SMB services, as the machine accounts created for each protocol can't share keytabs because of the potential for changes to the Key Version Number (kvno) in one keytab impacting the other service. As a result, the workflows for SMB services for Kerberos and NFS for Kerberos differ in functionality in some areas.

Initial configuration of Kerberos realm

The NFS Kerberos realm is configured when the Kerberos realm information is filled out in the Azure NetApp Files portal under the Active Directory connections page.

Screenshot of Kerberos realm configuration.

The Azure AD Server Name and KDC IP are used to connect to the Azure AD KDC services on the initial machine account creation. The Azure NetApp Files service leverages the existing domain information to fill out the rest of the realm configuration. For example:

Kerberos Realm: CONTOSO.COM
KDC Vendor: Microsoft
KDC IP Address: x.x.x.x 
KDC Port: 88
Clock Skew: 5
Active Directory Server Name: dc1.contoso.com
Active Directory Server IP Address: x.x.x.x
Comment: -
Admin Server IP Address: x.x.x.x
Admin Server Port: 749
Password Server IP Address: x.x.x.x
Password Server Port: 464
Permitted Encryption Types: aes-256
-    Configured by Azure NetApp Files administrator in the portal
-    Automatically configured by the service using Active Directory connection information/system defaults

When the NFS Kerberos realm is configured, a local hosts entry is added in the service with the KDC specified in the configuration. When the realm is modified, the local hosts entry is also modified in the service.

Diagram of Kerberos realm configuration.

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.

Initial creation of machine account/SPN

When Kerberos is enabled on an Azure NetApp Files volume, a machine account/principal named NFS-{SMB-server-name} is created in the domain in the specified OU in Active Directory connections (Organizational Unit). Machine account names are truncated after 15 characters.

Note

When adding Linux clients with hostnames greater than 15 characters to an Active Directory domain, their Kerberos machine account SPNs are truncated. For instance, a Linux client with a name of MORE-THAN-FIFTEEN has a machine account name of MORE-THAN-FIFT$, which becomes an SPN of MORE-THAN-FIFT$@CONTOSO.COM. When DNS looks up a client hostname, it finds the longer name and attempt to use that name in an SPN request ( MORE-THAN-FIFTEEN@CONTOSO.COM). Since that SPN doesn't exist, the client attempt to use the next SPN in the keytab in the request (usually host/hostname). Only machine account name SPNs natively work with Azure NetApp Files NFS Kerberos. As a result, ensure the Linux client hostnames used for NFS Kerberos with Azure NetApp Files don't exceed 15 characters. Alternately, if you want to use the host/hostname SPN, configure a UNIX user in LDAP with the username "host." This configuration provides a krb-unix name mapping for the SPN.

In Azure NetApp Files, Kerberos keyblocks (or keytab entries) are added to the service with the NFS service SPN (nfs/nfs-server-name.contoso.com@CONTOSO.COM). Multiple entries are created: one for each supported encryption type. In Azure NetApp Files, only the AES-256 encryption type is supported for NFS Kerberos.

In most cases, knowing these steps in depth won’t be necessary for day-to-day administration tasks, but are useful in troubleshooting any failures when attempting to create an NFS Kerberos volume in Azure NetApp Files.

NFS Kerberos SPN creation workflow

The following diagram shows how an NFS SPN is created when an Azure NetApp Files NFS or dual protocol volume is created with Kerberos enabled. In most cases, knowing detailed steps in depth won’t be necessary for day-to-day administration tasks, but are useful in troubleshooting any failures when attempting to create an SMB volume in Azure NetApp Files.

Diagram of NFS Kerberos SPN creation workflow.

For detailed steps about how an NFS Kerberos SPN is created with Azure NetApp Files, expand the list.
  • Admin credentials passed to KDC specified in the realm configuration using the username provided for use in the Active Directory connection – user must have permission to view/create objects in the specified OU.
  • The DNS servers specified in the Azure NetApp Files Active Directory connection configuration are queried by Azure NetApp Files for the Kerberos service records (SRV) in the following formats:
    • URI query for _kerberos.CONTOSO.COM
    • SRV query for _kerberos-master._udp. CONTOSO.COM
    • SRV query for _kerberos-master._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 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 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)
    • sAMAccountName (NFS-MACHINE$)
    • objectClass (top, person, organizationalPerson, user, computer)
    • servicePrincipalName (host/NFS-MACHINE, host/NFS-MACHINE.CONTOSO.COM, nfs/NFS-MACHINE, nfs/NFS-MACHINE.CONTOSO.COM)
    • userAccountControl (4096)
    • msDs-SupportedEncryptionTypes (AES-256_CTS_HMAC_SHA1_96)
    • dnsHostName (NFS-MACHINE.CONTOSO.COM)
  • The NFS kerberos machine account password is set for the NFS-MACHINE account over port 464.
  • Kerberos keyblocks (keytabs) for the NFS SPN are saved on the Azure NetApp Files service.
  • A static name mapping rule is created on the Azure NetApp Files service to ensure the root user for each NFS Kerberos client is mapped to root when Kerberos is used.
  • A krb5.conf file is added to the service’s internal systems with the NFS realm information.

NFS Kerberos mounts

When an Azure NetApp Files volume is mounted using Kerberos security flavors over NFS, the following workflow is performed. For a more detailed account of Kerberos, see Kerberos Network Authentication Service (V5) Synopsis.

Diagram of NFS Kerberos mount workflow.

For detailed steps about how an NFS Kerberos volume is mounted with Azure NetApp Files, expand the list.
  • The client attempts a mount to an NFS export path in Azure NetApp Files and specifies the -o krb5 (or krb5i or krb5p) security flavor.
  • DNS is used to formulate a request for an NFS service principal to Azure NetApp Files via either A/AAAA record or PTR (depending on how the mount command was issued).
  • The client retrieves a TGT from the KDC via an AS-REQ call using the CLIENT principal name found in the client's keytab.
  • The export path is checked to ensure it exists in the file system.
  • The export policy rule is checked to ensure that Kerberos access is allowed to the export path.<
  • The NFS service ticket is requested from the KDC by the client via an AP-REQ call. Azure NetApp Files checks the keytab for a valid entry with a valid encryption type using the TGT from the client acquired from the KDC.
  • If the TGT is valid, a service ticket is issued.
  • The client SPN (for instance, CLIENT$@CONTOSO.COM) is mapped to the root user via the name mapping rule in Azure NetApp Files.
  • The root user is queried in the name services databases (files and LDAP) for existence/group memberships.
  • An LDAP bind using the SMB server machine account is performed to allow an LDAP search for the root user.
  • Since root always exists in Azure NetApp Files, this shouldn't cause any issues, but LDAP queries for root might fail. These failures can be ignored.
  • The NFS service ticket is returned to the client and the mount is successful. The root user has root access to the Kerberos mount by way of the client’s machine account principal (viewable with the klist -e command from the client).
  • Azure NetApp Files adds entries to the Kerberos context cache for the client. These entries will reside in cache for the duration of the life of the Kerberos ticket set by the KDC and controlled by the Kerberos Policy.
  • NFSv4.1 periodically (every 20 seconds) sends a Kerberos ticket refresh updates as "keepalives."

NFS Kerberos mount access with user principals

When an Azure NetApp Files NFS Kerberos mount is accessed by a user (other than the root user, which uses the machine account SPN), the following workflow is performed.

Diagram of NFS Kerberos mount access with user principals.

For detailed steps about how an NFS Kerberos volume is accessed with a nonroot user with Azure NetApp Files, expand the list.
  • 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
  • Azure NetApp Files checks for a cached NFS service ticket. If none exist, then the NFS service ticket is requested via an AP-REQ call and the service checks the keytab for a valid entry with a valid encryption type using the TGT from the client acquired from the KDC
  • If the TGT is valid, a service ticket is issued
  • The user’s user principal name (UPN) is mapped through implicit mapping. For instance if the UPN is user1@CONTOSO.COM, then the service queries for a UNIX user named user1. Since that UNIX user doesn't exist in the local files database in Azure NetApp Files, LDAP is used.
  • An LDAP bind using the SMB server machine account is attempted to allow an LDAP search for the mapped user. A DNS SRV query is done for Kerberos DNS records (_kerberos and _kerberos-master). If no valid records can be used, then the configuration falls back onto the realm configuration. These KDC DNS SRV queries are not site scoped.
  • LDAP SRV records are queried for valid LDAP servers. These are site-scoped.
  • If the user doesn't exist in LDAP or LDAP can't be queried (server is down, DNS lookup fails, bind fails, LDAP search times out, user doesn't exist) then the mapping fails and access is denied.
  • If the user exists, group memberships are gathered.
  • The mapping succeeds and an NFS service ticket is issued to the client (seen in klist -e commands). Access is allowed based on the file permissions on the export path.

LDAP's role with Kerberos in Azure NetApp Files

Azure NetApp Files relies on LDAP for NFS Kerberos. NFS Kerberos in Azure NetApp Files requires Kerberos for UNIX name mappings for incoming user SPNs. Because Azure NetApp Files doesn't support creation of local UNIX users, LDAP is needed to perform lookups for UNIX users when a name mapping is requested.

  • When an Azure AD connection is created, the Active Directory domain name is used to specify the process to look up LDAP servers.
  • When an LDAP server is needed, _ldap.domain.com is used for the SRV lookup for LDAP servers.
  • Once a list of servers are discovered, the best available server (based on ping response time) is used as the LDAP server for connection over port 389.
  • An LDAP bind is attempted using the SMB machine account via GSS/Kerberos.
  • If there's no cached connection or Kerberos credentials, then a new request for a Kerberos ticket is issued. Cached connections for name servers in Azure NetApp Files live for 60 seconds. If idle for more than 60 seconds, the connection cache is cleared.
  • DNS is used to find the appropriate Kerberos KDCs via SRV records.
  • If no KDCs can be found via DNS query, the KDC specified in the krb5.conf file for the SMB services is used.
    • If that KDC is unreachable or can't process the Kerberos request, the LDAP bind fails. The name lookup also fails. Access is denied to the mount since no valid authentication took place.
    • If the bind succeeds, then an LDAP query is performed for the user and its credentials. If the search time exceeds 10 seconds, the search fails.
  • If the lookup finds the user, the mapping succeeds and access is granted via Kerberos (provided the ticket is valid/has not expired).

IP addresses for access with Kerberos

By default, Kerberos authentication leverages hostname-to-IP-address resolution to formulate the Service Principal Name (SPN) used to retrieve the Kerberos ticket. For example, when an SMB share is accessed with a Universal Naming Convention path (UNC) such as \SMBVOLUME.CONTOSO.COM, a DNS request is issued for the Fully Qualified Domain Name SMBVOLUME.CONTOSO.COM, and the IP address of the Azure NetApp Files volume is retrieved. If there's no DNS entry present (or the present entry is different from what's requested, such as with aliases/CNAMEs), then a proper SPN isn't able to be retrieved and the Kerberos request fails. As a result, access to the volume could be disallowed if the fallback authentication method (such as New Technology LAN Manager) is disabled.

DNS entries in Azure NetApp Files are created automatically using dynamic DNS and are formulated using the SMB server’s name. For any variations/aliases to the defined name, a manual DNS CNAME record should be created and pointed to the dynamic DNS entry. For more information, see Understand DNS in Azure NetApp Files.

NFSv4.1 Kerberos operates in a similar manner for SPN retrieval, where DNS lookups are integral to the authentication process and can also be used for Kerberos realm discovery.

If an IP address (rather than a hostname) is used in an access request to an Azure NetApp Files volume, then a Kerberos request operates differently depending on the protocol in use.

SMB Kerberos behavior with IP addresses and DNS names

When using SMB, a request for a UNC path using an IP address (for example, \\x.x.x.x) by default attempts to use NTLM for authentication. In environments where NTLM is disallowed for security reasons, an SMB request using an IP address isn't able to use Kerberos or NTLM for authentication by default. As a result, access to the Azure NetApp Files volume is denied. In later Windows releases (beginning with Windows 10 version 1507 and Windows Server 2016), Kerberos clients can be configured to support IPv4 and IPv6 hostnames in SPNs for SMB communication to work around this issue.

NFSv4.1 Kerberos behavior with IP addresses and DNS names

When using NFSv4.1, a mount request to an IP address using one of the sec=[krb5/krb5i/krb5p] options uses reverse-DNS lookups via PTR to resolve an IP address to a hostname. That hostname is then used to formulate the SPN for Kerberos ticket retrieval. If you use NFSv4.1 with Kerberos, you should have an A/AAAA and PTR for the Azure NetApp Files volume to cover both hostname and IP address access to mounts. Azure NetApp Files creates a dynamic DNS A/AAAA record. If a reverse DNS zone exists for that subnet, a PTR record is automatically created also. For deviations from the standard Azure NetApp Files hostname conventions, use CNAME records for DNS aliases.

For more information, see Understand DNS in Azure NetApp Files