5.1. Accounts Authentication¶
- Password Policy
- Windows Domain Accounts on servers running Active Directory
- Per-account access restrictions based on source IP address
- Allowing users to change their own password
- Disabling all users from a group
- Inherited Home Folder Path and Authorized SSH Keys File
- Account setup for anonymous authentication
SFTPPlus provides multiple ways in which an account or administrator can be authenticated.
The server-side security of SFTPPlus is designed based on the Authentication, Authorization and Accounting (AAA) components.
Here are a few methods / sources used to authenticate accounts. For a full list please check the authentication methods configuration:
- Anonymous Account
- Application Account (SFTPPlus accounts persisted in a configuration file)
- Operating System Local Account
- Windows Domain Accounts
- Legacy SFTPPlus WebAdmin accounts
- HTTP resource
These accounts can be authenticated by various types of credentials. Below is a list of supported credentials:
- Username and password provided by the operating system
- Username and password via a domain controller
- Username and password provided in a configuration file
- Username and SSH RSA/DSA keys
- Username and SSL certificates.
SSH RSA/DSA keys credentials are only available when used with SFTP.
SSL certificate credentials are only available when used with FTPS.
On the Windows operating system, SSH RSA/DSA key and SSL certificates credentials are only available for application accounts, i.e. Windows local or domain accounts can be authenticated only based on username and password credentials.
While supporting multiple authentication methods and hence multiple account identity providers, there is the risk of overlapping account names / IDs, the same account being provided by multiple sources.
The server will check each authentication method in the configured order and will stop checking other providers at the first source accepting or rejecting the credentials. If the source cannot give an accept / reject answer, since the account name / ID is unknown, the server will ask the next identity source provider.
The authentication process will check to see if there is a valid request for a new file transfer session. If the check confirms the provided credentials, it will return the configuration for the requested account.
In SFTPPlus you can define the password policy used when setting new passwords.
NIST’s current password guidelines from 2018, as defined in Special Publication 800-63-3 Digital Authentication Guidelines, include:
- Minimum password length should be 8 characters, with a maximum of no less than 64
- All ASCII and UNICODE characters should be allowed
- Check against a list of “known-bad” passwords
- Remove knowledge-based authentication
- Stop practice of regular password expiration
- Don’t allow password hints
- Remove composition rules (i.e., “your password needs to contain at least one upper and lowercase character and one special character”), and instead focus on longer passwords
- Passwords need to be hashed, salted and stretched
Below you can find how SFTPPlus matches the NIST recommendations:
- You can configure the minimum size for passwords, and SFTPPlus allows setting passwords as long as 200 characters.
- The default security policy requires a password of minimum 11 characters.
- When the password strength check is enabled, passwords are checked against a list of common, weak, or bad passwords. The check includes dates and usernames.
- All ASCII and Unicode characters are allowed.
- Knowledge-based authentication and password hints are not available in SFTPPlus.
- Passwords are hashed and salted before being stored, and these operations are repeated 80.000 times for each password.
The password policy used to check newly defined password is configured via the following configuration options from the [server] section:
- password_minimum_strength - enforce a minimum strength
- password_minimum_length - enforce a minimum length
The password strength policy is designed to replace the composite policy rules that often fail both ways, allowing weak passwords (such as P@ssword1) and disallowing strong passwords (such as Wow...doestcst).
To require a password policy with a minimum of 12 characters and strength of best you can define it as:
[server] password_minimum_strength = 4 password_minimum_length = 12
The password strength is determined using the zxcvbn password strength estimator created by Daniel Lowe Wheeler from Dropbox Inc.
How does SFTPPlus authenticate Windows Domain accounts?
SFTPPlus uses the Windows API to authenticate Windows Domain accounts via a Domain Controller, the server running the Active Directory service.
This option only works on Windows machines which is part of the domain as a “member server”.
In terms of SFTPPlus configuration, the software does not interact directly with Active Directory nor the LDAP server in creating an account.
SFTPPlus only uses the existing Windows authentication capabilities of existing accounts.
There are 3 main configuration cases:
- Domain account configured via default group
- Domain accounts configured via augmented SFTPPlus config
- Domain account configured via augmented SFTPPlus config with inherited values from group
This guide focuses on the first two cases.
As for the final case, as this is not a common case, please email Pro:Atria should you require support.
While this guide is written for those new to SFTPPlus in mind, administrators can also edit these configurations through the text file equivalent residing in the server.ini configuration file.
The following will help guide you in setting up a new SFTPPlus os account that is an existing Windows Domain account.
This setup adds an authentication layer on top of the OS account and thus allowing account access and ability to conduct file transfers using SFTPPlus.
These steps assume that the OS account/s and settings already exists.
In Local Manager, create a new Account with the type Operating System (os).
If the new SFTPPlus os account is a Windows Domain Controller Account, the username is provided in the UPN format (like email@example.com). This format is needed if there is an Active Directory forest.
You can allow the account to create a new folder in the account using the home folder’s path (c:\\ftp-files) and make sure to lock access.
When SFTPPlus first authenticates the account firstname.lastname@example.org, it will create a folder for the username as the home folder path.
In the screenshot below, we can see that for email@example.com, SFTPPlus will create a folder in the home folder path.
The final path for this account is now c:\\ftp-files\\john.
For those setting up multiple accounts, they have the additional option of using the groups configuration.
In this way, groups is used to configure the ‘Missing home folder’ section.
In the screenshot below, the missing home folder is configured so that the OS account is the owner of this folder.
The account is then associated with this group in the Accounts section for that particular account.
One item to note is that if the user configuration is missing and then this DEFALT_GROUP is used.
Should there be issues in authenticating, make sure to check the server logs or the activity reports available in the Local Manager GUI.
For example, if the device has connectivity issues with the domain controller (if the account is a domain controller account), there may be problems authenticating the surrounding services that use it, such as SFTPPlus. The issue may be transient, or if it’s ongoing please check with the administrator of the domain controller.
Another common error is to list the account’s UUID as part of the authentication method for the service that the account will be using to transfer files (such as ftp). This method should only be used for authentication UUID, not the account UUID.
If you are intending to use another type of authentication, such as an LDAP bind, make sure that this authentication method UUID is added to the service.
Using a firewall, you can configure the networking layer to only allow connections to the file transfer service from a set of IP addresses.
Once a source IP passes the firewall, connections originating from it can be associated to and authenticated against any available account.
Using the account or group source_ip_filter configuration though, you can restrict the access of a source IP to only a specific account or group.
Below is an example in which the automation group configuration doesn’t allow the account to be authenticated from any source IP address, while account billing-sap is configured to explicitly allow authentication from source IPs 10.0.2.45 or 10.0.2.46:
[groups/87dc321-87dc-aedf-1123-cd5328aef4] name = automation enabled = Yes source_ip_filter = block-all [accounts/5432ca3-bbd5-9432-be31-b4318ddea4] name = billing-sap enabled = yes type = application group = 87dc321-87dc-aedf-1123-cd5328aef4 description = Account used by billing automation system to pull reports. source_ip_filter = 10.0.2.45, 10.0.2.46
You can configure whether to allow file transfer users to change their own password, or whether to have their password updated only by administrators.
Only application accounts defined inside SFTPPlus Local Manager can have their password changed.
Operating system accounts, domain accounts, LDAP accounts, and other accounts defined in external systems can’t have their password changed via SFTPPlus.
When an account is allowed to change its own password, it can do this using the password update command available for each transfer protocol.
FTP/FTPS, SFTP/SCP, and HTTP/HTTPS protocols, each have a different method to change the current user’s password. You can find more details about changing the password as part of the operational documentation for each protocol / file transfer service type.
For example, in the following configuration we have user johnd, which can change its own password, and user billing-sap, which can’t change its own password:
[groups/2fd149b3-9fdb-49d0-8666-3c28f151f64d] name = partners enabled = Yes allow_own_password_change = Yes [groups/87dc321-87dc-aedf-1123-cd5328aef4] name = automation enabled = Yes allow_own_password_change = No [accounts/92ad5b32-d8d7-4ed8-94e1-dbb9f01383f4] name = johnd enabled = yes type = application group = 2fd149b3-9fdb-49d0-8666-3c28f151f64d description = Account used by John Doe from ACME Inc to push reports. [accounts/5432ca3-bbd5-9432-be31-b4318ddea4] name = billing-sap enabled = yes type = application group = 87dc321-87dc-aedf-1123-cd5328aef4 description = Account used by billing automation system to pull reports.
The Enabled configuration option for a group, affects the state of all users from that group.
For example, the following configuration will disable access to any account from the partners group, while the accounts from the accounting group will have access granted based on the account’s configuration:
[groups/0a3f3aa7-50d2-44ef-9456-4f0beb69cf7d] name = accounting enabled = Yes [groups/804aab78-70c0-4e1d-8480-4979e169a0a2] name = partners enabled = No
While a group is enabled, specific accounts can be disabled by setting the enabled property for the specific account.
In Accounts, create an account of type Application Account. Since it is used for anonymous authentication, choose a relevant name. Configure its home folder.
In Authentications, ensure that anonymous authentication is defined/enabled. Edit the account’s method configuration and select a user to be mapped to the anonymous account. This user will be the account that was recently created in the first paragraph of this section.
Go to the Status page and double check that the anonymous authentication method referred to above is running (started).
If not, manually start it.
In the Server page, make a note of all existing UUIDs in the Authentications field.
In the Status page, select to edit select to edit the configuration of the service you want to allow the anonymous account to.
Add all the UUIDs that are already used globally including the UUID from the anonymous authentication.
In the Server page, add the UUID of the authentication method to the Authentications list.
To locate this UUID, go to the Authentications page, select the anonymous authentication method and copy the Identifier string.
Run a test on the service to ensure the new settings are applied.
The following events represent a successful anonymous authentication:
20137 2016-12-13 14:23:29 test-server-uuid Unknown 127.0.0.1:4831 Account “user” of type “application” authenticated as “anonymous” by anonymous authentication “auth-anonymous” using password.20182 2016-12-13 14:23:29 Process user 127.0.0.1:4831 Account “user” logged in.