Using local user authentication
Many SMB clients require a user to be identified by a username and domain. When using local user authentication, the domain may be any string you choose and need not correspond to any other domain in use on the network, the IP of any EVS, or any SMB name.
Note that it is common to use ALL CAPS for domain names, but it is not a requirement.
Procedure
To add user alice in domain EXAMPLE, with password Alligat0r, enter:
local-password-set EXAMPLE\alice Alligat0r If preferred, the password may be entered interactively by omitting the password from the above command and then entering the password when prompted. Note that interactive entry limits password length to 127 characters. All three fields are case sensitive, with EXAMPLE\Alice, example\alice and EXAMPLE\alice considered three separate users.To see which users are configured, enter:
local-password-list All configured users are shown, along with their stored password hashes.To delete a single user, in this case, bob in domain EXAMPLE , enter:
local-password-delete EXAMPLE\bobTo irreversibly delete all configured users, enter:
local-password-delete-all --confirmFTP: To use local user authentication with FTP, enable SMB-based authentication with:
ftp-cfg --ntsecurity on
SID mappings
The owner (typically the creator) of any file is identified by a Security Identifier (SID) associated with that user. The local users feature does not automatically create an SID for each user, so you must assign SIDs.
To assign SIDs:
Procedure
To assign SID S-1-81-1 to user EXAMPLE\david, enter:
user-mappings-add --nt-name EXAMPLE\david --nt-id S-1-81-1 If an SID is not assigned to a local user in this way, that user will still be able to authenticate but will be treated as the Anonymous Logon user. You should ensure that any SIDs are assigned before a user connects, as any changes will not take effect while they remain connected.Typically, a user would also have a primary group SID (used to give a group to files created by that user) and may be a member of one or more additional groups. These may be configured using the primary-group-set and localgroup commands, respectively.
$ primary-group-set "Unix user\1234" "Unix group\1234" $ localgroup add "Backup Operators" "Unix user\521" No programmatic assistance is provided for allocating SIDs. Instead, it is recommended that the first local user be given the SID S-1-81-0; the second, S-1-81-1, and so on. It is recommended that the first locally allocated group be given the SID S-1-82-0; the second, S-1-82-1, and so on.Use user-mappings-list to see users with SIDs assigned.
Configuration
NTLMv2 authentication for local users using the NTOWF_V2 hash is not supported in versions prior to 12.3, is supported but is disabled by default in version 12.3, and is supported and enabled by default in versions 12.4 and later. The NAS server does not store user passwords in plain text. Instead, user passwords are passed through a variety of one-way functions to produce hashes; these do not permit retrieval of the originally entered password.
To perform NTLMv2 authentication using the NTOWF_V2 hash:
Procedure
Ensure the appropriate password hashes are available.
The server calculates up to four of these hashes: NTOWF_V1, LMOWF_V1, NTOWF_V2 and LMOWF_V2, with the set shown by the local-password-list command dependent on your configuration.The server may also store passwords encoded using a two-way function. While passwords encoded this way are not stored as plain text, a skilled attacker could reverse the two-way function to obtain the original input. Consequently, it is recommended to disable the two-way function in version 12.3 and later. For version 12.3 and later, disable the two-way function using:
set shouldKeepObfuscatedLocalPasswords false Note that you should only use this command once you are sure you do not wish to downgrade past version 12.3; software versions prior to this do not support one-way hashes and rely on the two-way function encoding to authenticate local users. Disabling the two-way function and downgrading will result in local users being unable to authenticate unless their passwords are reset.In versions that support it, NTLMv2 authentication for local users using the NTOWF_V2 hash may be enabled with:
set ntlmV2-authentication-allowed true This is a cluster-wide setting, is persistent across reboots, and will take immediate effect. NTLMv2 has long been supported for externally managed users.