Setting authentication preferences

Top  Previous  Next

Users may authenticate with MFT Server using a variety of different authentication protocols.  To view the current authentication method used click on the Authentication node for the desired domain.

 

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

Password Hashing

Multi-Factor Authentication

Web SSO

 

Domain User Authentication

 

Domain User Authentication is the most basic form of authentication, authenticating against local user accounts created for the domain using MFT Server Manager.

 

Figure 58

 

clip0058

 

 

 

Database Authentication

 

Database Authentication allows you to authenticate a user based on whether the user has credentials to connect to a database.  When connecting to the supplied JDBC URL the username and password provided at time of login are used to login to the JDBC URL.  If user authenticates successfully with the JDBC URL then user is considered a valid user of the MFT Server service.

 

Figure 59

 

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  in order for the database to be accessible to MFT Server.  

 

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

 

Convert username before creation to - If enabled, the username supplied will be converted to specified case before passing username to specified User Template.

 

Database Query Authentication

 

Database Query Authentication allows you to authenticate a user based on the results of a database query.  If one or more records are returned from the query then the user is successfully authenticated.

 

 

Figure 60

 

clip0060

 

 

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 in order for the database to be accessible to MFT Server

 

Username - The username to connect with when authenticating with JDBC database.

 

Password - The password to connect with when authenticating with JDBC database.

 

SQL query - The query to perform to authenticate the user.   There are two special variables that may be used when performing the database query %username% and %password% which refer the username and password passed in during the authentication process.  Note, SQL queries and stored procedures may be used, however stored procedures which make use of output parameters may not be used.  The variables %username% and %password% are treated as strings so must be enclosed in single quotes.

 

Hash password class - The Java class to use for hashing password before passing to SQL query.  If no class is specified then password will be passed to SQL query in clear text.

 

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

 

Convert username before creation to - If enabled, the username supplied will be converted to specified case before passing username to specified User Template.

 

See also

 

Password Hashing

 

 

LDAP Authentication

 

LDAP User Authentication allows you to authenticate a user based on whether the user has the credentials to connect to the LDAP or Active Directory service.

 

 

Figure 61

 

clip0061

 

 

Host - The hostname or IP address of the LDAP service.

 

Port - The port of the LDAP service.

 

Timeout - The connection timeout when connecting to LDAP service.

 

User DN - The users distinguished name for authenticating with the LDAP service. The variable %username% may be used which refers to the username passed in during the authentication process.

 

Use SSL connection - Connect to LDAP server using SSL connection.

 

Allow anonymous binding - Sets whether user can bind anonymously to LDAP directory.

 

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

 

Convert username before creation to - If enabled, the username supplied will be converted to specified case before passing username to specified User Template.

 

Use failover server - If enabled and primary LDAP server is inaccessible then authentication will be attempted against failover server.

 

 

LDAP Query Authentication

 

LDAP Query Authentication allows you to authenticate a user based on the results of a LDAP query and is a two step  authentication process.

 

1.User is authenticated against LDAP server using the User DN field and the password supplied by user when authenticating against MFT Server file transfer service.
2.Query is performed using credentials supplied in Search user DN and Password fields.  Note, these credentials may be different than the credentials used in Step 1.  For example, a case where these might be different is where the User DN does not have the needed permissions to perform the query but the Search User DN does.

 

If one or more records are returned from the query then the user is successfully authenticated.

 

Figure 62

 

clip0062

 

 

Host - The hostname or IP address of the LDAP service.

 

Port - The port of the LDAP service.

 

Timeout - The connection timeout when connecting to LDAP service.

 

User DN - The users distinguished name for authenticating with the LDAP service.

 

Search user DN - The user distinguished name used for performing LDAP search query.

 

Password - The user password for performing LDAP search query.

 

Base DN - The base distinguished name in which to perform the filter.

 

Filter - The filter to execute using the LDAP filter syntax.  There are two special variables that may be used when performing the database query, %username% and %password% which refer the username and password supplied by the user during the authentication process.

 

Hash password class - The Java class to use for hashing password before passing to filter.  If no class is specified then password will be passed to Filter in clear text.

 

Use SSL connection - Connect to LDAP server using SSL connection.

 

Allow anonymous binding - Sets whether user can bind anonymously to LDAP directory.

 

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

 

Convert username before creation to - If enabled, the username supplied will be converted to specified case before passing username to specified User Template.

 

Use failover server - If enabled and primary LDAP server is inaccessible then authentication will be attempted against failover server.

 

See also

 

Password Hashing

 

 

LDAP Filter Grammar

 

When using LDAP Query Authentication you must define a filter that will be used to identify the record you are searching for.  The syntax of LDAP filters are 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

 

Using NTLM Authentication you may authenticate against an existing Windows domain.

 

Figure 118

 

clip0118

 

Host - The IP address of Windows domain controller.

 

Windows domain - The name of the Windows domain to which users belong.

 

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

 

Convert username before creation to - If enabled, the username supplied will be converted to specified case before passing username to specified User Template.

 

 

 

PAM Authentication

 

Using PAM Authentication you may authenticate against an existing UNIX PAM user repository.  In order 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 Libary Path.  See the Native Library Installation Location table for details.   Note, Step 1 in the JPam instructions should 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 native library in 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 native library in the Java Native Library Path and not in the libs directory of MFT Server.
3.Configure JPam for use by editing the net-sf-jpam file and copying it to to /etc/pam.d directory.
4.Restart MFT Server Service.
5.Using MFT Server Manager go to the Authentication node and set the Service type to PAM authentication and enable other options.  See Figure 117.
6.Click Test Parameters button to test.

 

 

Figure 117

 

clip0117

 

 

Enable debug to file system_output.log - Sends debugging information to file system_output.log in installation directory.

 

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

 

Convert username before creation to - If enabled, the username supplied will be converted to specified case before passing username to specified User Template.

 

RADIUS Authentication

 

 

Using RADIUS authentication you may authenticate against an existing RADIUS server.

 

Figure 208

 

clip0208

 

 

Local address - The local UDP address for socket binding.

 

Server address - The server address of RADIUS server.

 

Server port - The server port of RADIUS server.

 

Timeout - The timeout in seconds for connecting to RADIUS server.

 

Max retransmit attempts - The maximum number of retransmission attempts when there is no response from the RADIUS server

 

Identifier - The identifier value of the RADIUS server.

 

Shared secret - The shared secret value of the RADIUS server.

 

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

 

Convert username before creation to - If enabled, the username supplied will be converted to specified case before passing username to specified User Template.

 

 

Custom Authentication

 

Using custom authentication you may define your own custom authentication class.

 

Figure 86

 

clip0086

 

 

 

Authentication class - The custom authentication class name.

 

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

 

Convert username before creation to - If enabled, the username supplied will be converted to specified case before passing username to specified User Template.

 

See also

 

Authenticating using custom authentication API

 

 

Multiple Authentication

 

Multiple authentication enables you to authenticate users using multiple authentication service types. 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.

 

Figure 235

 

 

clip0235

 

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

 

 

When you choose Multiple Authentication, you need to define a Primary and Secondary authentication type. The configuration details of each service type are the same as those described above.

 

When authenticating, the user is first authenticated against the Primary service. If the authentication is successful, the user is granted access. If the authentication fails, a second authentication attempt is made against the Secondary service. If the second authentication also fails, then the user is denied access; otherwise, access is granted.

 

Note For purposes of IP blocking/banning and raising of User Login event, this should only happen either after successful login OR after both Primary and Secondary authentication methods have been attempted.

 

 

 

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 in order to protect user credentials should a database or LDAP repository be compromised.  MFT Server includes some built-in classes that may be 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 offer MD5 and SHA1 hashes respectively.  Note, 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.  In a salted hash format the password is combined with other data (the salt) prior to being hashed.  Salted hash passwords are typically used in an effort to avoid brute-force password attacks should the database or LDAP repository be compromised.  Password salting is generally application dependent, therefore should you need to use a salted password it is necessary to write your own password hasher using the MFT Server API.  To implement your own password hashing provider you must perform the following:

 

1.  Create a Java class which 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 will need to include the ftpserver.jar library in your classpath.  The ftpserver.jar library may be found in the libs directory for MFT Server.

 

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

 

5.  Shutdown 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 package name of your hash provider.

 

Multi-Factor Authentication

 

 

See Using Multi-Factor Authentication

 

 

Web SSO

 

SSO (Single-Sign-On) is a method by which users can login to one service (identity provider) and automatically be granted access to other services (service provider) without the need to login separately to these other services.  An example of this would be logging into Google Apps and automatically be granted access to your MFT Server account without the need for a separate login.  In the example screenshot below (Figure 171) Google Apps would serve as the identity provider and your MFT Server instance as the service provider.  MFT Server provides support for web based SSO using SAML, OpenID and OpenID Connect compliant identity providers.  Please consult the documentation of your identity provider for details on how to enable/configure SSO.

 

Login URL

 

To perform a web SSO login use the following URL format:

 

https://[hostname]/sso/[domainname]/login

 

For example, if your hostname is 1.2.3.4 and your domain is mydomain this URL would look as follows:

 

https://1.2.3.4/sso/mydomain/login

 

If you have already authenticated with your identity provider then you will be automatically logged into MFT Server.  If not, then you will be redirected to the Sign-in URL for your identity provider.  After authenticating with your identity provider you will be automatically logged into MFT Server.

 

Note

 

SSO applies only to web based sessions.  Other protocols (FTP/S, SFTP, WebDAV, AFTP etc.) will authenticate users using the defined authentication service for the domain.

 

OpenID Connect Example (Google Identity Platform)

 

The example provided below is for connecting with the Google Identity Platform.  Sensitive information has been masked in the screenshot below.

 

 

Figure 171

 

clip0171

 

 

 

Authorization URL - The URL used for signing into the identity provider.

 

Token verification URL - The URL for verifying tokens.

 

Client ID - Your client ID for connecting with identity provider.

 

Client secret - Your client secret for connecting with identity provider.

 

Create user if not found using template - This allows for accounts to be created automatically upon successful authentication.  If selected, an account will be created automatically (if it does not exist already) using the specified User Template.  The Name and Login properties for the account created will automatically be set to the openid.identity attribute value.

 

Convert username before creation to - If enabled, the username supplied will be converted to specified case before passing username to specified User Template.

 

Allow non SSO logins - If enabled, user may login using either SSO or other authentication service

 

 

 





Home | Company | Products | Solutions | Purchase | Support | Services | Blog

© 2022 Redwood Software, Inc.