Skip to main content
NetApp Solutions

SMB

Contributors kevin-hoke
PDFs

SMB is a network file sharing protocol developed by Microsoft that provides centralized user/group authentication, permissions, locking, and file sharing to multiple SMB clients over an Ethernet network. Files and folders are presented to clients by way of shares, which can be configured with a variety of share properties and offers access control through share-level permissions. SMB can be presented to any client that offers support for the protocol, including Windows, Apple, and Linux clients.

Google Cloud NetApp Volumes provides support for the SMB 2.1 and 3.x versions of the protocol.

Access control/SMB shares

  • When a Windows username requests access to the Google Cloud NetApp Volumes volume, Google Cloud NetApp Volumes looks for a UNIX username using the methods configured by Google Cloud NetApp Volumes administrators.

  • If an external UNIX identity provider (LDAP) is configured and Windows/UNIX usernames are identical, then Windows usernames will map 1:1 to UNIX usernames without any additional configuration needed. When LDAP is enabled, Active Directory is used to host those UNIX attributes for user and group objects.

  • If Windows names and UNIX names do not match identically, then LDAP must be configured to allow Google Cloud NetApp Volumes to use the LDAP name mapping configuration (see the section “Using LDAP for asymmetric name mapping”).

  • If LDAP is not in use, then Windows SMB users map to a default local UNIX user named pcuser in Google Cloud NetApp Volumes. This means files written in Windows by users that map to the pcuser show UNIX ownership as pcuser in multiprotocol NAS environments. pcuser here is effectively the nobody user in Linux environments (UID 65534).

In deployments with SMB only, the pcuser mapping still occurs, but it won’t matter, because Windows user and group ownership is correctly displayed and NFS access to the SMB-only volume is not allowed. In addition, SMB-only volumes do not support conversion to NFS or dual-protocol volumes after they are created.

Windows leverages Kerberos for username authentication with the Active Directory domain controllers, which requires a username/password exchange with the AD DCs, which is external to the Google Cloud NetApp Volumes instance. Kerberos authentication is used when the \\SERVERNAME UNC path is used by the SMB clients and the following is true:

  • DNS A/AAAA entry exists for SERVERNAME

  • A valid SPN for SMB/CIFS access exists for SERVERNAME

When a Google Cloud NetApp Volumes SMB volume is created, the machine account name is created as defined in the section “How Google Cloud NetApp Volumes shows up in Active Directory." That machine account name also becomes the SMB share access path because Google Cloud NetApp Volumes leverages Dynamic DNS (DDNS) to create the necessary A/AAAA and PTR entries in DNS and the necessary SPN entries on the machine account principal.

Note For PTR entries to be created, the reverse lookup zone for the Google Cloud NetApp Volumes instance IP address must exist on the DNS server.

For example, this Google Cloud NetApp Volumes volume uses the following UNC share path: \\cvs-east- 433d.cvsdemo.local.

In Active Directory, these are the Google Cloud NetApp Volumes-generated SPN entries:

Figure showing input/output dialog or representing written content

This is the DNS forward/reverse lookup result:

PS C:\> nslookup NetApp Volumes-EAST-433D
Server:  activedirectory. region. lab. internal
Address:  10. xx.0. xx
Name:    NetApp Volumes-EAST-433D.cvsdemo.local
Address:  10. xxx.0. x
PS C:\> nslookup 10. xxx.0. x
Server:  activedirectory.region.lab.internal
Address:  10.xx.0.xx
Name:    NetApp Volumes-EAST-433D.CVSDEMO.LOCAL
Address:  10. xxx.0. x

Optionally, more access control can be applied by enabling/requiring SMB encryption for SMB shares in Google Cloud NetApp Volumes. If SMB encryption isn’t supported by one of the endpoints, then access is not allowed.

Using SMB name aliases

In some cases, it might be a security concern for end users to know the machine account name in use for Google Cloud NetApp Volumes. In other cases, you might simply want to provide a simpler access path to your end users. In those cases, you can create SMB aliases.

If you want to create aliases for the SMB share path, you can leverage what is known as a CNAME record in DNS. For example, if you want to use the name \\CIFS to access shares instead of \\cvs-east- 433d.cvsdemo.local, but you still want to use Kerberos authentication, a CNAME in DNS that points to the existing A/AAAA record and an additional SPN added to the existing machine account provides Kerberos access.

Figure showing input/output dialog or representing written content

This is the resulting DNS forward lookup result after adding a CNAME:

PS C:\> nslookup cifs
Server:  ok-activedirectory.us-east4-a.c.cv-solution-architect-lab.internal
Address:  10. xx.0. xx
Name:    NetApp Volumes-EAST-433D.cvsdemo.local
Address:  10. xxx.0. x
Aliases:  cifs.cvsdemo.local

This is the resulting SPN query after adding new SPNs:

Figure showing input/output dialog or representing written content

In a packet capture, we can see the Session Setup Request using the SPN tied to the CNAME.

Figure showing input/output dialog or representing written content

SMB authentication dialects

Google Cloud NetApp Volumes supports the following dialects for SMB authentication:

  • LM

  • NTLM

  • NTLMv2

  • Kerberos

Kerberos authentication for SMB share access is the most secure level of authentication you can use. With AES and SMB encryption enabled, the security level is further increased.

Google Cloud NetApp Volumes also supports backward compatibility for LM and NTLM authentication. When Kerberos is misconfigured (such as when creating SMB aliases), share access falls back to weaker authentication methods (such as NTLMv2). Because these mechanisms are less secure, they are disabled in some Active Directory environments. If weaker authentication methods are disabled and Kerberos is not configured properly, share access fails because there is no valid authentication method to fall back to.

For information about configuring/viewing your supported authentication levels in Active Directory, see Network security: LAN Manager authentication level.

Permission models

NTFS/File permissions

NTFS permissions are the permissions applied to files and folders in file systems adhering to NTFS logic. You can apply NTFS permissions in Basic or Advanced and can be set to Allow or Deny for access control.

Basic permissions include the following:

  • Full Control

  • Modify

  • Read & Execute

  • Read

  • Write

When you set permissions for a user or group, referred to as an ACE, it resides in an ACL. NTFS permissions use the same read/write/execute basics as UNIX mode bits, but they can also extend to more granular and extended access controls (also known as Special Permissions), such as Take Ownership, Create Folders/Append Data, Write Attributes, and more.

Standard UNIX mode bits do not provide the same level of granularity as NTFS permissions (such as being able to set permissions for individual user and group objects in an ACL or setting extended attributes). However, NFSv4.1 ACLs do provide the same functionality as NTFS ACLs.

NTFS permissions are more specific than share permissions and can be used in conjunction with share permissions. With NTFS permission structures, the most restrictive applies. As such, explicit denials to a user or group overrides even Full Control when defining access rights.

NTFS permissions are controlled from Windows SMB clients.

Share permissions

Share permissions are more general than NTFS permissions (Read/Change/Full Control only) and control the initial entry into an SMB share—similar to how NFS export policy rules work.

Although NFS export policy rules control access through host-based information such as IP addresses or host names, SMB share permissions can control access by using user and group ACEs in a share ACL. You can set share ACLs either from the Windows client or from the Google Cloud NetApp Volumes management UI.

By default, share ACLs and initial volume ACLs include Everyone with Full Control. The file ACLs should be changed but share permissions are overruled by the file permissions on objects in the share.

For instance, if a user is only allowed Read access to the Google Cloud NetApp Volumes volume file ACL, they are denied access to create files and folders even though the share ACL is set to Everyone with Full Control, as shown in the following figure.

Figure showing input/output dialog or representing written content

Figure showing input/output dialog or representing written content

For best security results, do the following:

  • Remove Everyone from the share and file ACLs and instead set share access for users or groups.

  • Use groups for access control instead of individual users for ease of management and faster removal/addition of users to share ACLs through group management.

  • Allow less restrictive, more general share access to the ACEs on the share permissions and lock down access to users and groups with file permissions for more granular access control.

  • Avoid general use of explicit deny ACLs, because they override allow ACLs. Limit use of explicit deny ACLs for users or groups that need to be restricted from access to a file system quickly.

  • Make sure that you pay attention to the ACL inheritance settings when modifying permissions; setting the inheritance flag at the top level of a directory or volume with high file counts means that each file below that directory or volume has inherited permissions added to it, which can create unwanted behavior such as unintended access/denial and long churn of permission modification as each file is adjusted.

SMB share security features

When you first create a volume with SMB access in Google Cloud NetApp Volumes, you are presented with a series of choices for securing that volume.

Some of these choices depend on the Google Cloud NetApp Volumes level (Performance or Software) and choices include:

  • Make snapshot directory visible (available for both NetApp Volumes-Performance and NetApp Volumes-SW). This option controls whether or not SMB clients can access the Snapshot directory in an SMB share (\\server\share\~snapshot and/or Previous Versions tab). The default setting is Not Checked, which means that the volume defaults to hiding and disallowing access to the ~snapshot directory, and no Snapshot copies appear in the Previous Versions tab for the volume.

Figure showing input/output dialog or representing written content

Hiding Snapshot copies from end users might be desired for security reasons, performance reasons (hiding these folders from AV scans) or preference. Google Cloud NetApp Volumes Snapshots are read- only, so even if these Snapshots are visible, end users cannot delete or modify files in the Snapshot directory. File permissions on the files or folders at the time the Snapshot copy was taken apply. If a file or folder’s permissions change between Snapshot copies, then the changes also apply to the files or folders in the Snapshot directory. Users and groups can gain access to these files or folders based on permissions. While deletes or modifications of files in the Snapshot directory are not possible, it is possible to copy files or folders out of the Snapshot directory.

  • Enable SMB encryption (available for both NetApp Volumes-Performance and NetApp Volumes-SW). SMB encryption is disabled on the SMB share by default (unchecked). Checking the box enables SMB encryption, which means traffic between the SMB client and server is encrypted in-flight with the highest supported encryption levels negotiated. Google Cloud NetApp Volumes supports up to AES-256 encryption for SMB. Enabling SMB encryption does carry a performance penalty that might or might not be noticeable to your SMB clients—roughly in the 10-20% range. NetApp strongly encourages testing to see if that performance penalty is acceptable.

  • Hide SMB share (available for both NetApp Volumes-Performance and NetApp Volumes-SW). Setting this option hides the SMB share path from normal browsing. This means that clients that do not know the share path cannot see the shares when accessing the default UNC path (such as \\NetApp Volumes-SMB). When the checkbox is selected, only clients that explicitly know the SMB share path or have the share path defined by a Group Policy Object can access it (security through obfuscation).

  • Enable access-based enumeration (ABE) (NetApp Volumes-SW only). This is similar to hiding the SMB share, except the shares or files are only hidden from users or groups that do not have permissions to access the objects. For instance, if Windows user joe is not allowed at least Read access through the permissions, then the Windows user joe cannot see the SMB share or files at all. This is disabled by default, and you can enable it by selecting the checkbox. For more information on ABE, see the NetApp Knowledge Base article How does Access Based Enumeration (ABE) work?

  • Enable Continuously Available (CA) share support (NetApp Volumes-Performance only). Continuously Available SMB shares provide a way to minimize application disruptions during failover events by replicating lock states across nodes in the Google Cloud NetApp Volumes backend system. This is not a security feature, but it does offer better overall resiliency. Currently, only SQL Server and FSLogix applications are supported for this functionality.

Default hidden shares

When an SMB server is created in Google Cloud NetApp Volumes, there are hidden administrative shares (using the $ naming convention) that are created in addition to the data volume SMB share. These include C$ (namespace access) and IPC$ (sharing named pipes for communication between programs, such as the remote procedure calls (RPC) used for Microsoft Management Console (MMC) access).

The IPC$ share contains no share ACLs and cannot be modified—it is strictly used for RPC calls and Windows disallows anonymous access to these shares by default.

The C$ share allows BUILTIN/Administrators access by default, but Google Cloud NetApp Volumes automation removes the share ACL and does not allow access to anyone because access to the C$ share allows visibility into all mounted volumes in the Google Cloud NetApp Volumes file systems. As a result, attempts to navigate to \\SERVER\C$ fail.

Accounts with local/BUILTIN administrator/backup rights

Google Cloud NetApp Volumes SMB servers maintain similar functionality to regular Windows SMB servers in that there are local groups (such as BUILTIN\Administrators) that apply access rights to select domain users and groups.

When you specify a user to be added to Backup Users, the user is added to the BUILTIN\Backup Operators group in the Google Cloud NetApp Volumes instance that uses that Active Directory connection, which then gets the SeBackupPrivilege and SeRestorePrivilege.

When you add a user to Security Privilege Users, the user is given the SeSecurityPrivilege, which is useful in some application use cases, such as SQL Server on SMB shares.

Figure showing input/output dialog or representing written content

You can view Google Cloud NetApp Volumes local group memberships through the MMC with the proper privileges. The following figure shows users that have been added by using the Google Cloud NetApp Volumes console.

Figure showing input/output dialog or representing written content

The following table shows the list of default BUILTIN groups and what users/groups are added by default.

Local/BUILTIN group Default members

BUILTIN\Administrators*

DOMAIN\Domain Admins

BUILTIN\Backup Operators*

None

BUILTIN\Guests

DOMAIN\Domain Guests

BUILTIN\Power Users

None

BUILTIN\Domain Users

DOMAIN\Domain Users

*Group membership controlled in Google Cloud NetApp Volumes Active Directory connection configuration.

You can view local users and groups (and group members) in the MMC window, but you cannot add or delete objects or change group memberships from this console. By default, only the Domain Admins group and Administrator are added to the BUILTIN\Administrators group in Google Cloud NetApp Volumes. Currently, you cannot modify this.

Figure showing input/output dialog or representing written content

Figure showing input/output dialog or representing written content

MMC/Computer Management access

SMB access in Google Cloud NetApp Volumes provides connectivity to the Computer Management MMC, which allows you to view shares, manage share ACLs, ands view/manage SMB sessions and open files.

To use the MMC to view SMB shares and sessions in Google Cloud NetApp Volumes, the user logged in currently must be a domain administrator. Other users are allowed access to view or manage the SMB server from MMC and receive a You Do Not Have Permissions dialog box when attempting to view shares or sessions on the Google Cloud NetApp Volumes SMB instance.

To connect to the SMB server, open Computer Management, right click Computer Management and then select Connect To Another Computer. This opens the Select Computer dialog box where you can enter the SMB server name (found in the Google Cloud NetApp Volumes volume information).

When you view SMB shares with the proper permissions, you see all available shares in the Google Cloud NetApp Volumes instance that share the Active Directory connection. To control this behavior, set the Hide SMB Shares option on the Google Cloud NetApp Volumes volume instance.

Remember, only one Active Directory connection is allowed per region.

Figure showing input/output dialog or representing written content

Figure showing input/output dialog or representing written content

The following table shows a list of supported/unsupported functionality for the MMC.

Supported functions Unsupported functions

  • View shares

  • View active SMB sessions

  • View open files

  • View local users and groups

  • View local group memberships

  • Enumerate the list of sessions, files, and tree connections in the system

  • Close open files in the system

  • Close open sessions

  • Create/manage shares

  • Creating new local users/groups

  • Managing/viewing existing local user/groups

  • View events or performance logs

  • Managing storage

  • Managing services and applications

SMB server security information

The SMB server in Google Cloud NetApp Volumes uses a series of options that define security policies for SMB connections, including things such as Kerberos clock skew, ticket age, encryption, and more.

The following table contains a list of those options, what they do, the default configurations, and if they can be modified with Google Cloud NetApp Volumes. Some options do not apply to Google Cloud NetApp Volumes.

Security option What it does Default value Can change?

Maximum Kerberos Clock Skew (minutes)

Maximum time skew between Google Cloud NetApp Volumes and domain controllers. If the time skew exceeds 5 minutes, Kerberos authentication fails. This is set to the Active Directory default value.

5

No

Kerberos Ticket Lifetime (hours)

Maximum time a Kerberos ticket remains valid before requiring a renewal. If no renewal occurs before the 10 hours, you must obtain a new ticket. Google Cloud NetApp Volumes performs these renewals automatically. 10 hours is the Active Directory default value.

10

No

Maximum Kerberos Ticket Renewal (days)

Maximum number of days that a Kerberos ticket can be renewed before a new authorization request is needed. Google Cloud NetApp Volumes automatically renews tickets for SMB connections. Seven days is the Active Directory default value.

7

No

Kerberos KDC Connection Timeout (secs)

The number of seconds before a KDC connection times out.

3

No

Require Signing for Incoming SMB Traffic

Setting to require signing for SMB traffic. If set to true, clients that do not support signing fail connectivity.

False

Require Password Complexity for Local User Accounts

Used for passwords on local SMB users. Google Cloud NetApp Volumes does not support local user creation, so this option does not apply to Google Cloud NetApp Volumes.

True

No

Use start_tls for Active Directory LDAP Connections

Used to enable start TLS connections for Active Directory LDAP. Google Cloud NetApp Volumes does not currently support enabling this.

False

No

Is AES-128 and AES-256 Encryption for Kerberos Enabled

This controls whether AES encryption is used for Active Directory connections and is controlled with the Enable AES Encryption for Active Directory Authentication option when creating/modifying the Active Directory connection.

False

Yes

LM Compatibility Level

Level of supported authentication dialects for Active Directory connections. See the section “SMB authentication dialects” for more information.

ntlmv2-krb

No

Require SMB Encryption for Incoming CIFS Traffic

Requires SMB encryption for all shares. This is not used by Google Cloud NetApp Volumes; instead, set encryption on a per-volume basis (see the section “SMB share security features”).

False

No

Client Session Security

Sets signing and/or sealing for LDAP communication. This is not currently set in Google Cloud NetApp Volumes but might be needed in future releases to address . Remediation for LDAP authentication issues due to the Windows patch is covered in the section “LDAP channel binding.”.

None

No

SMB2 enable for DC connections

Uses SMB2 for DC connections. Enabled by default.

System-default

No

LDAP Referral Chasing

When using multiple LDAP servers, referral chasing allows the client to refer to other LDAP servers in the list when an entry is not found in the first server. This is currently not supported by Google Cloud NetApp Volumes.

False

No

Use LDAPS for Secure Active Directory Connections

Enables the use of LDAP over SSL. Currently not supported by Google Cloud NetApp Volumes.

False

No

Encryption is required for DC Connection

Requires encryption for successful DC connections. Disabled by default in Google Cloud NetApp Volumes.

False

No