User Authentication

There are several authentication options you can choose from to secure User access to MFT Server. Users are the people who connect to your MFT Server to upload and download files. User Authentication is configured in the [Domain] >  ACCOUNTS > Authentication > Authentication module.

 

Below is a list of supported authentication types. The Database Query Authentication and LDAP Query Authentication services also support optional Password Hashing.

 

Domain User Authentication

Database Authentication

Database Query Authentication

LDAP Authentication

LDAP Query Authentication

LDAP Filter Grammar

NTLM Authentication

PAM Authentication

RADIUS Authentication

Custom Authentication

Multiple Authentication

 

Domain User Authentication

 

Domain user authentication is the most basic form of authentication. Authentication uses local User accounts created in a Domain. See the image below, where the Service type field is domain user authentication. When this authentication option is selected, an MFT Server Administrator must create Users in the Domain ACCOUNTS > Users > Users grid, then provide each User with their Login and Password. The password is stored encrypted in the MFT Server database.

 

Note: You can require the User to change the password the first time they log in by enabling the Domain SECURITY > Compliance > Compliance > Require password reset on first time login field.

 

clip0058

 

General Information about non-local authentication service types

 

For the remaining authentication Service types described below (excluding domain user authentication), the authentication takes place using a service outside the realm of MFT Server. That said, there still must be a record for the User in the MFT Server's Domain ACCOUNTS > Users > Users grid. This record is used for authorization purposes (the permissions associated with the User). There are two ways to manage creating the User account in the Users grid.

 

  1. Create the User account (prior to the User logging in) in the Domain ACCOUNTS > Users > Users grid. The ACCOUNTS > Users > Users > Login field should be assigned the same login value (typically the user name) that is used to authenticate the User for the selected Service type.

     

    Example: When using database authentication, if the User logs in to the database with a username of Jsmith, that same username must be the value entered in the Users > Login field.

     

    The Login field is always unique. The ACCOUNTS > Users > Users > Password field is not used since authentication occurs using the Service type configured. As mentioned earlier, the password is only used for the domain user authentication service type.

     

  2. Let MFT Server create the User in the Domain ACCOUNTS > Users > Users grid, during the log in process, if a record for the account does not exist. This feature is enabled by checking the ACCOUNTS > Authentication > Authentication > Service type > Create user if not found using <template> field. When this option is enabled, the following will occur after the User successfully authenticates using the configured Service type:  

     

    • If a record does not exist in the ACCOUNTS > Users > Users grid (the Login field is the search field used), then one is created for the user by MFT Server. The new User's Login field is assigned the same value the User entered (username) when they authenticated using the selected Service type. A random system-generated password is assigned to the new User account. As stated in item 1, the password field is not used for authentication when an authentication method outside MFT Server is used. Therefore, the value of the random password is irrelevant.

     

    Note: The <template> selected is important because the field settings on the template are assigned to the new User account. This includes authorization settings such as the virtual path(s) the User will have access to along with the associated permissions (e.g., download file, upload file, list files, etc.).  

  • If a record does exist in the Accounts > Users > Users grid (the Login field is the search field used), then the record is used for authorization purposes, and the login will be successful.

 

If the Create user if not found using <template> field is not checked, and a matching record is not found in the ACCOUNTS > Users > Users grid (it was not manually created, as described in item 1), the login fails. The login also fails if the User does not authenticate using the Service type selected.

 

Database Authentication

 

 

Database authentication lets you authenticate a User based on their rights to connect to a database that you specify. The user name and password provided at time of the MFT server log in are used to connect to the database identified in the JDBC URL. If the User authenticates successfully using the JDBC URL, the User is considered a valid User of the MFT Server service.

 

clip0059

 

JDBC URL — The JDBC URL used to connect to the database. Libraries for JDBC drivers must be placed in the libs/jdbc directory of your MFT Server installation, and the MFT Server service must be restarted for the database to be accessible to MFT Server.  

 

Create user if not found using template — If selected, and the User authenticates successfully, the User is created automatically (if it does not already exist) using the specified User Template.

 

Convert username before creation to <uppercase | lowercase> — If selected, the username supplied is converted to upper or lowercase before passing the user name to the specified User Template.

 

Database Query Authentication

 

 

Database Query authentication lets you authenticate a User based on the results of a database query. If one or more records are returned from the query, the User is authenticated.

 

clip0060

 

JDBC URL — Identifies the JDBC URL used to connect to the database. Libraries for JDBC drivers must be placed in the libs/jdbc directory of your MFT Server installation, and the MFT Server Service must be restarted for the database to be accessible to MFT Server.

 

Username — Identifies the username to connect with when authenticating using a JDBC database.

 

Password — Identifies the password to connect with when authenticating using a JDBC database.

 

SQL Query — Identifies the query to execute when authenticating the User. Two special variables can be used when performing the database query: %username% and %password%. They refer to the username and password passed during the authentication process.

 

Note: SQL queries and stored procedures may be used. However, stored procedures that use output parameters are not supported. The variables %username% and %password% are treated as strings, therefore they must be enclosed in single quotes.

 

Hash password class — Identifies the Java class for password hashing before passing it to the SQL query.  If no class is specified, the password is passed to the SQL query in clear text.

 

Create user if not found using template — If selected and the User authenticates successfully, the User is created automatically (if it does not already exist) using the specified User Template.

 

Convert username before creation to <uppercase | lowercase> — If selected, the username supplied is converted to upper or lowercase before passing the user name to the specified User Template.

 

See also

 

Password Hashing

 

LDAP Authentication

 

LDAP User authentication lets you authenticate a User based on their ability to connect to an LDAP or Active Directory service.

 

clip0061

 

Host — Identifies the hostname or IP address of the LDAP service.

 

Port — Identifies the port of the LDAP service.

 

Timeout — Identifies the connection timeout when connecting to the LDAP service.

 

User DN — Identifies user Distinguished Name (DN) when authenticating with the LDAP service. The variable %username% can be used. It refers to the user name passed during the authentication process.

 

Use SSL connection — If selected, the connection to the LDAP server uses an SSL connection.

 

Allow anonymous binding — If selected, a user can bind anonymously to the LDAP directory.

 

Create an account if not found using a template - This allows for accounts to be created automatically upon successful authentication. If selected, an account is created automatically (if it does not exist already) using the specified User Template.

 

Convert username before creation to <uppercase | lowercase> — If selected, the username supplied is converted to upper or lowercase before passing the user name to the specified User Template.

 

Use failover server — If selected, authentication is attempted against the failover server if the primary LDAP server becomes inaccessible.

FAILOVER SERVER

Host — Identifies the LDAP failover server host.

 

Port — Identifies the LDAP failover server port.

 

LDAP Query Authentication

 

 

LDAP Query authentication lets you authenticate a User based on the results of an LDAP query. This is a two-step authentication process.

 

  1. The Admin is authenticated against the LDAP server using the User DN field and password supplied by the user.

  2. The query uses the credentials supplied in Search user DN and Password fields.

 

Note: The Search user DN credentials may be different from those used in Step 1. A scenario where they may differ is when the User DN does not have the required permissions to perform the query, but the Search User DN does.

 

If one or more records are returned from the query, the User is authenticated.

 

 

Host — Identifies the hostname or IP address of the LDAP service.

 

Port — Identifies the port of the LDAP service.

 

Timeout — Identifies the connection timeout when connecting to the LDAP service.

 

User DN — Identifies the user's Distinguished Name when authenticating with the LDAP service.

 

Search user DN — Identifies the user's Distinguished Name for performing the LDAP search query.

 

Password — Identifies the user password for performing the LDAP search query.

 

Base DN — Identifies the base Distinguished Name to perform the Filter.

 

Filter — Identifies the filter to execute using LDAP filter syntax. Two special variables may be used when performing the database query: %username% and %password%. They refer to the username and password supplied by the User during the authentication process.

 

Hash password class — Identifies the Java class for hashing the password before passing it to Filter.  If no class is specified, the password is passed to Filter in clear text.

 

Use SSL connection — If selected, connect to the LDAP server using an SSL connection.

 

Create user if not found using template — If selected and the User authenticates successfully, the User is created automatically (if it does not already exist) using the specified User Template.

 

Convert username before creation to <uppercase | lowercase> — If selected, the username supplied is converted to upper or lowercase before passing the user name to the specified User Template.

 

Use failover server — If selected, authentication is attempted against the failover server if the primary LDAP server becomes inaccessible.

 

FAILOVER SERVER

Host — Identifies the LDAP failover server host.

 

Port — Identifies the LDAP failover server port.

 

LDAP Filter Grammar

 

When using LDAP Query Authentication, you must define a filter that is used to identify the record you are searching for. The syntax for LDAP filters is defined in RFC 2254. The table below provides a list of valid expressions and their meanings.

 

Symbol Filter Example Example matches

=

Equality

(sn=Smith)

Surname of Smith only.

>

Greater than

(sn>Smith)

Any surname that alphabetically follows Smith.

>=

Greater than or equal to

(sn>=Smith)

Any surname that includes or alphabetically follows Smith.

<

Less than

(sn<Smith)

Any surname that alphabetically precedes Smith.

<=

Less than or equal to

(sn<=Smith)

Any surname that includes or alphabetically precedes Smith.

=*

Presence

(sn=*)

All surnames (all entries with the sn attribute).

=*

Substring

(sn=Smi*)

Any matching substring of Smith.

&

And

(& (sn=Smith) (cn=John) )        

Surname of Smith and common name of John.

|

Or

(| (sn=Smith) (sn=Jones) )

Surname of Smith or Jones.

!

Not

(! (sn=Smith))

Surname not equal to Smith.

 

See also

 

Authenticating with Microsoft Active Directory

 

NTLM Authentication

 

 

NTLM authentication lets you authenticate a User against an existing Windows domain.

 

clip0118

 

Host — Identifies the IP address of the Windows domain controller.

 

Windows domain — Identifies the name of the Windows domain to which the users belong.

 

Create user if not found using template — If selected and the User authenticates successfully, the User is created automatically (if it does not already exist) using the specified User Template.

 

Convert username before creation to <uppercase | lowercase> — If selected, the username supplied is converted to upper or lowercase before passing the username to the specified User Template.

 

PAM Authentication

 

 

PAM authentication lets you authenticate Users using an existing UNIX PAM user repository. To use the PAM Authentication module, you must install some native libraries that allow MFT Server to communicate with your PAM user repository.

 

  1. Download the JPam library for your operating system.

  2. Copy the native library to the Java Native Library Path. See the Native Library Installation Location table for details.

     

     

    Note: Step 1, as found in the JPam instructions, must be ignored as the jpam.jar file already exists in the libs directory of your MFT Server installation. Additionally, JPam instructions state you may optionally place the native library in the same directory as the jpam.jar file instead of the Java Native Library Path. This is incorrect. For JPam to work with MFT Server, you must place the native library in the Java Native Library Path and not in the libs directory of MFT Server.

     

  3. Configure JPam by editing the net-sf-jpam file and copying it to /etc/pam.d directory.

  4. Restart the MFT Server service.

  5. Using the MFT Server Manager, navigate to the ACCOUNTS > Authentication > Authentication tab and set the Service type to PAM authentication, and enable other options.

  6. Click Test Parameters to test the connection.

 

clip0117

 

 

Enable debug to file system_output.log — If selected, this sends debugging information to the file system_output.log located in the installation directory.

 

Create user if not found using template — If selected and the User authenticates successfully, the User is created automatically (if it does not already exist) using the specified User Template.

 

Convert username before creation to <uppercase | lowercase> — If selected, the username supplied is converted to upper or lowercase before passing the username to the specified User Template.

 

RADIUS Authentication

 

 

RADIUS authentication lets you authenticate a User against an existing RADIUS server.

 

clip0208

 

Local address — Identifies the local UDP address for socket binding.

 

Server address — Identifies the Radius server address.

 

Server port — Identifies the RADIUS server port.

 

Timeout — Identifies the timeout (in seconds) for connecting to the RADIUS server.

 

Max retransmit attempts — Identifies the maximum number of retransmission attempts when there is no response from the RADIUS server.

 

Identifier — Identifies the RADIUS server Identifier value.

 

Shared secret — Identifies the RADIUS server'sshared secret value.

 

Create user if not found using a template — This allows for accounts to be created automatically upon successful authentication.  If selected, an account is created automatically (if it does not exist already) using the specified User Template.

 

Convert username before creation to <uppercase | lowercase> — If enabled, the username supplied is converted to upper or lowercase before passing the username to the specified User Template.

 

Custom Authentication

 

 

Custom authentication lets you define your own custom authentication class to use for User authentication.

 

clip0086

 

Authentication class — The custom authentication class name.

 

Create user if not found using template — If selected and the User authenticates successfully, the User is created automatically (if it does not already exist) using the specified User Template.

 

Convert username before creation to <uppercase | lowercase> — If selected, the username supplied is converted to upper or lowercase before passing the username to the specified User Template.

 

See also

 

Authenticating using custom authentication API

 

Multiple Authentication

 

 

Multiple authentication lets you authenticate Users using multiple authentication service types. If the 1st authentication type does not succeed, the next authentication type in the ordered list is used. This continues until a successful authentication occurs, or the list is exhausted and the authentication fails. One example use case is when you have some internal users who need to be authenticated using LDAP authentication and some external users who need to be authenticated using domain user authentication.

 

 

Note: Multiple authentication is NOT 2-factor authentication or multi-factor authentication.

 

When you choose Multiple Authentication, you must define at least 2 types of authentication. You will not be able to save what you enter for Multiple Authentication if you only define 1 authentication service type. Click on the Add button (which was done in the above image) and select the first service you wish to configure from the droplist list. You are allowed to configure up to 5 authentication service types. You can use the same type more than once, using different parameters. The configuration details of each service type are the same as those described above.

 

When authenticating, the User is first authenticated against the 1st service (the Order column displays 1st, 2nd, etc.). If authentication is successful, the User is granted access using the 1st service. If authentication fails, a second authentication attempt is made using the second service. If successful, the User is granted access. If the second authentication fails, what happens next depends on whether another service is configured. If no other service is configured, the User is denied access. If a third authentication service is configured, that is used next. The same pattern will continue, for each service configured. The system goes down the ordered list but stops when it can authenticate the User. If none of the authentication services succeed, the User is not granted access.

 

The Move Up and Move Down buttons allow you to change the order of your 2 or more services.

 

Note: For purposes of IP blocking/banning and raising the User Login Trigger event, these actions occur only after all authentication methods have been attempted or a successful User login is achieved.

 

Password Hashing

 

The Database Query Authentication and LDAP Query Authentication services both support optional password hashing.  Many databases and LDAP repositories store passwords in a hashed format. This is a security measure used to protect User credentials in the event a database or LDAP repository is compromised. MFT Server includes some built-in classes that are used for hashing a password before it is sent for authentication against a database or LDAP repository.  

 

These classes are com.jscape.inet.mft.authentication.MD5Hasher and com.jscape.inet.mft.authentication.SHA1Hasher, which offers MD5 and SHA1 hashes, respectively. The hashes provided by the MD5Hasher and SHA1Hasher classes are provided in lowercase format.

 

Some databases or LDAP repositories may store passwords in a salted hash format. This means the password is combined with other data (the salt) prior to being hashed. Salted hash passwords are typically used to avoid brute-force password attacks if the database or LDAP repository is compromised. Password salting is generally application-dependent; therefore, if you need to use a salted password, you must write your own password hasher using an MFT Server API. To implement your own password hashing provider, follow the steps below.

 

  1. Create a Java class that implements the com.jscape.inet.mft.authentication.Hasher class.

     

  2. Overload the public String createHash(String login, String password) method, returning the hashed value.

     

  3. Create a JAR file that contains the compiled version of your com.jscape.inet.mft.authentication.Hasher implementation. To compile your authentication class, you must include the ftpserver.jar library in your classpath. The ftpserver.jar library is located in the libs directory of MFT Server.

     

  4. Place the JAR file created in step 3 in the libs directory of your MFT Server installation.

     

  5. Shut down any open instances of MFT Server Manager and restart the MFT Server service.

     

  6. In the Hash password class field of the Database Query Authentication or LDAP Query Authentication service, enter the full classname, including the package name of your hash provider.