Description of the MFT login-audit file

MFT logs each logon and logoff event in the login-audit file.  This file is written to folder:
    <MFT-Install>/logs/audit
A file is written for each day a login occurs.  The format of the file is:
    login-audit-yyyy-mm-dd.log

Originally, this file was meant to collect debugging information.  However, customers want to use this as a way to validate successful and failed logon attempts.  So the product was updated to allow customers to use this file to track successful and failed logons.  This file still contains debugging information; however this document shows how users can utilize this file to track successful and failed logon and logoff requests.  

Logons and logoffs are tracked for all incoming protocols: FTP/FTPS, SFTP, HTTP/HTTPS, Platform Server and AS2.
The way that logons are tracked depends on the way MFT Servers define authentication and how authentication is performed by the end user.  MFT supports the following authentication methods:

• Password Only
• Key/Certificate only
• Password and Key/Certificate
• Password or Key/Certificate

In some cases, where both certificate and password, or certificate or password, are defined users may get multiple audit records written.  For example:
When the Authentication method is set to certificate or password, you could get:

• A Failed password Login
• A Successful certificate login 

Note: When an SSH password is not entered, MFT will not log a password failure.

This document explains the fields in the login-audit file and the values allowed for each field.  

Sample Login-Audit records:
Examples of login-audit records:
04.27.2018 16:18:54 , status: 0, User: test, IP: 127.0.0.1, Protocol: FTP, Action: 2, Description: , ServerName: NYMFTIS1, Authenticate Methods: Database_Password
04.27.2018 16:18:54 , status: 0, User: test, IP: 127.0.0.1, Protocol: FTP, Action: 20, Description: , ServerName: NYMFTIS1, Authenticate Methods: N/A
04.27.2018 16:18:58 , status: 0, User: test, IP: 127.0.0.1, Protocol: FTP, Action: 3, Description: , ServerName: NYMFTIS1, Authenticate Methods: N/A


Description of Login-Audit fields:
==========================================================================================================
1. AUDIT FORMAT
==========================================================================================================
Each Login-Audit record documents a single event.  The fields below are included in each record; fields are delimited by a comma.  

• Date:  Date and time the event occurred
• Status:  Event status
• User:  Userid that initiated the event
• IP:  Originating IP Address
• Protocol:  Originating client protocol
• Action:  Event Action
• Description:  Event Description
• ServerName:  MFT Server Name where the event occurred
• Authenticate Methods:  The authentication method attempted

Below are descriptions of the the fields along with possible values for each field:

Date:
Defines the date and time that the event occurred.

Status:
Defines whether the logon or logoff request was successful, failed, etc.  

User:
Defines the user that initiated the event.  

IP:
Defines the IP Address of the client user that initiated the request.  If the request came through a load balancer, this IP Address will most likely be the IP Address of the load balancer and not the client IP Address.
    
Protocol:
Defines the Client protocol that initiated the action.  Protocols can be HTTP, FTP, SSH, PS(Platform Server) or AS2.

Action:
Defines the action that caused the record to be written.
Actions values useful for auditing:

Information and debugging actions:

Description:
Some Actions and/or protocols include a description of the event.

Server Name:
Defines the name of the Internet Server or Command Center where the event occurred.
    
Authenticate Methods:
This information is for action=2 (User logon attempt) only. It does not apply to other actions.

Informational Methods:

    

Examples:
Example 1: 04.27.2018 16:18:54 , status: 0, User: test, IP: 127.0.0.1, Protocol: FTP, Action: 2, Description: , ServerName: NYMFTIS1, Authenticate Methods: Database_Password
Example 2: 04.27.2018 16:18:54 , status: 0, User: test, IP: 127.0.0.1, Protocol: FTP, Action: 20, Description: , ServerName: NYMFTIS1, Authenticate Methods: N/A
Example 3: 04.27.2018 16:18:58 , status: 0, User: test, IP: 127.0.0.1, Protocol: FTP, Action: 3, Description: , ServerName: NYMFTIS1, Authenticate Methods: N/A

Example 1:

• The event occurred on 04/27/2017 at 16:18:54
• Status=0 indicates that this was a successful request
• User "test" initiated this event
• The IP Address that initiated this request was 127.0.0.1
• Action=2 indicates a login request
• Description: 
• Server Name: This event occurred on server "NYMFTIS1"
• Authentication Method "Database_Password" indicated that the user was a DB user and used a password to login.  

Example 2:

• The event occurred on 04/27/2017 at 16:18:54
• Status=0 indicates that this was a successful request
• User "test" initiated this event
• The IP Address that initiated this request was 127.0.0.1
• Action=20 indicates that the user passed authentication.  Note that this request is related to Example 1 and will only be displayed after a successful login attempt (for Action=2)
• Description: 
• Server Name: This event occurred on server "NYMFTIS1"
• Authentication Method "N/A" - Authentication Methods are only displayed for Action=2 (User login request).

Example 3:

• The event occurred on 04/27/2017 at 16:18:58
• Status=0 indicates that this was a successful request
• User "test" initiated this event
• The IP Address that initiated this request was 127.0.0.1
• Action=3 indicates that the user logged off.  
• Description: 
• Server Name: This event occurred on server "NYMFTIS1"
• Authentication Method "N/A" - Authentication Methods are only displayed for Action=2 (User login request).

==========================================================================================================
2. Behavior on different Client Protocols
==========================================================================================================
The logging may behave differently based on incoming client protocol and user's authentication type. 

Only action 2, 20, and 3 are guaranteed to be accurate based on the following specification of how MFT defined a logon attempt.  Other actions are used for debugging purposes only.

FTP/SSH/PS Protocols:

Note: The number of failed requests can vary based on the client protocol when "Password or Key/Certificate" or "Password and Key/Certificate" is defined, because clients, particularly SSH, request authentication differently.

Special behavior for each protocol:

-------------------------
HTTP Protocol
    All certificate and password authentication will be logged, regardless of the user's authorization type.
    Browser may initiate many authorization requests if the certificate authorization failed because of browsers use multiple connections to retrieve resources from server.
    
-------------------------
AS2 Protocol
    If MFT finds a match on a Server definition's Partner AS2 Id and the UserId associated with AS2 server definition, authentication is successful; otherwise the authentication is logged as a failure.
    AS2 logoff requests are not logged, since there is no AS2 logoff protocol.  
    
-------------------------
SAML Authentication
    Since the SAML IDP performs authentication, only successful login requests are logged.  
    
-------------------------
SSO and RADIUS Authenticate
    The logging described in this document for Radius and SSO is for debugging purposes only.