Login to EFT (WTC)

The EFT administrator should inform end users which IP address, port, username, and password should be used to log in to a Site. Because many users are unfamiliar with <IP address:Port> formatting, be sure to provide users with the exact URL that they should access to log in, whether they are accessing a Site from the Web Transfer Client, "plain-text" client, a command line, CuteFTP, or any other FTP client. For example, you could provide a link in an e-mail or tell your users:

In the address box of Internet Explorer, type https://wtc.mycompany.com:4434

To log in to EFT to transfer files

  1. Open a web browser to the address provided by the EFT administrator. For example, https://mycompany.com/EFTClient/Account/Login.htm. The login page appears.

  2. Provide your EFT Username and Password, and then click Log In.

    • If you have forgotten your username or password, click the applicable link. You will be asked for your email address to which the reset information will be sent.

    • If the Web Transfer Client is not enabled, a less-featured version of the WTC appears.

    • If it is configured in the EFT administration interface, users are prompted to change their password the first time they log in.

    • If a security prompt appears asking you to accept the website's certificate, select the Always trust check box, and then click Yes.

  3. Refer to Web Transfer Client (WTC) for details of transferring files.

Form-Based Authentication versus Basic Authentication

(Requires the HTTP/S module in EFT Express)

EFT uses form-based authentication for users that connect over a browser. It is important to note that a browser is defined merely by what is contained in the "user-agent" attribute provided in the HTTP headers. If EFT doesn’t recognize the user-agent (such as when connecting with a client application CuteFTP), then EFT will fall back to "basic authentication." There is nothing inherently wrong with basic authentication, especially if it is SSL encrypted, but form-based is considered superior because it facilitates true session management. However, there is another option, which is NTLM authentication, in which EFT attempts to reuse the user’s AD credentials as supplied by the browser (assuming the browser supports NTLM), resulting in a single-sign-on (SSO) experience. For example, the user authenticates on the company portal, and those credentials are reused by EFT without having to ask the user to re-enter them. The downside to NTLM-based authentication is that, like basic authentication, it does not support true sessions, so it is up to the users to close their browsers at the end of their sessions to truly log out. Another drawback is that when using NTLM, the end user won’t be able to choose between loading the Web Transfer Client or the Plain Text Client, won’t be able to access the lost username/password forms, and won’t see any of the custom branding. Each of these would be available to the user if they had used the default form-based authentication. Even in the case where NTLM is enabled, SSO will only apply for Active Directory-based sites (because we are talking about AD credentials), and the browser has to be a recognizable user-agent; otherwise, it will default to basic authentication (for non-browser) or form-based authentication (for non-AD sites), even if NTLM is turned on in the registry.  

  • If NTLM is off (by default), then EFT will use form-based authentication for recognized user-agents and basic-authentication for all others

  • If NTLM is on (registry enabled), then EFT will use NTLM authentication for AD sites + recognized user-agent, form based authentication for non-AD sites + recognized user agent, and basic authentication for all others (non-recognized user agents).

Related Topics