End-User Login In to EFT Server

The EFT Server 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

If you login to localhost or the IP address, you will be prompted for your Windows credentials. If using the fully qualified domain name, then you should not see a prompt and your current login credentials will be used. (This is a function of Integrated Windows Authentication (IWA), not EFT Server.)

To log in to EFT Server to transfer files

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

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

  3. Refer to Web Transfer Client (WTC) or Using the Plain-Text Client (PTC) for details of transferring files.

Form-Based Authentication versus Basic Authentication

EFT Server 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 Server doesn’t recognize the user-agent, such as when connecting with a client application like Curl or CuteFTP, then EFT Server 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 Server 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 Server 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 user to close their browser at the end of a session 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 (as 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.