Name of the MFT Web User.

Status of the MFT Web User. The MFT Web User can be enabled or disabled.

The MFT Web User first name.

The MFT Web User last name.

The primary email address of the MFT Web User. An email address should be specified if the MFT Web User receives email communication for account creation, password reset, forgot password or they have access to Secure Mail.

The description is optional information pertaining to the MFT Web User. This field is limited to 512 characters.

The company or organization which the MFT Web User belongs to.

Specify which technique should be used to authenticate the MFT Web User. Valid methods are Active Directory (AD), LDAP, LDAP Managed Server, and Native.

Passwords for MFT Web User accounts can be generated automatically based on the MFT Web User Password Policy. Otherwise the MFT Web User Manager creating the account can manually specify a password. If specifying the password, you are alerted if the password does not meet the MFT Web User Password Policy. The maximum password length is 20 characters.

The Authentication Type can be specified per service. For example, an MFT Web User can be forced to use a Password and Certificate when authenticating to FTPS but only require a Password for HTTPS. If a certificate is used for authentication, the Client Authentication setting on the SSL tab of the specific service must be set to Optional or Required.

The AS2 ID of the MFT Web User. The AS2 ID is case sensitive and can be 1 to 128 ASCII printable characters in length.

This is the alias of the public certificate used by this MFT Web User to sign their messages. If the certificate is signed by a certificate authority (for example, Verisign), this field can be left blank since the certificate chain already exists in the Default Trusted Certificates Key Store. If a specific certificate is to be used by the Web User for signing messages or they use a self-signed certificate, then that certificate should be imported into the Default Trusted Certificates Key Store. For more information, see the

Informatica Managed File Transfer Guide

.

The location where AS2 messages are saved when received (uploaded). The default location is the default home directory for the MFT Web User, which is the

[installdirectory]/userdata/webdocs/[webuser]

folder, where

[installdirectory]

is the installation directory of Managed File Transfer and

[webuser]

is the account name of the Web User.

The action that Informatica Managed File Transfer performs when a file with the same name already exists in the default upload folder.

This option indicates whether or not messages sent by this MFT Web User must be encrypted.

A signed message contains a digital signature from the sender to further authenticate the message. If signatures are required, any unsigned message sent by this MFT Web User will be rejected.

Require username/password or certificate authentication for messages uploads. If authentication is not required, Informatica Managed File Transfer will use the AS2 ID to identify the Web User. Informatica recommends you set the 'Require Signature' option to 'true' when authentication is not required.

If a return receipt is requested by the MFT Web User, select if the MDN will be sent automatically during the MFT Web User session or manually after the message is processed. A manual receipt can only be sent if a message is received successfully. If an error occurs during transmission, an asynchronous receipt is sent automatically.

The name identifies the SSH key. The maximum length of the name is 64 characters.

The algorithm to use when generating the key. Valid values are RSA and DSA. It is generally recommended to use RSA.

The length (in bits) of the key. Valid values are 512, 1024, 2048 or 4096 bits. Large key sizes will provide strong protection, but will slow the performance of encryption/decryption processes.

This is the password that protects the private key portion of the SSH Key Pair and should be recorded in a safe place.

The format in which to store the public key. Valid values are OpenSSH or SecureShell. It is generally recommended to use OpenSSH unless your trading partner dictates otherwise.

A description to store with the key. This typically should contain the name of your organization (for example, "ABC Company SSH Key"), which will allow others to quickly identify the key.

The name of the user that created the SSH key.

The date that the user created the SSH key.