|
|
|
|
|
MOVEit Transfer provides the ability to authenticate users to external LDAP and/or RADIUS servers. Microsoft Active Directory (AD) operates as an LDAP server, so MOVEit Transfer can authenticate to it natively. Both of these can be secured at the transport level (we encourage the use of LDAP over SSL/TLS) and related credentials are stored encrypted on MOVEit Transfer.
In addition to authenticating existing users against external sources, MOVEit Transfer can create new users, often as a clone of an existing template user. MOVEit Transfer also can split an organization's user base into External Users and Internal Users, with one group using an external authentication source and the other using the MOVEit Transfer built-in user database. When accessing an LDAP server, MOVEit Transfer can replicate group membership information and information such as email address from that LDAP server as well.
For enterprise environments, you can implement external authentication for MOVEit Transfer that provides Single Sign-on (SSO) behavior. There are several approaches to this. These include but are not limited to the following:
An Authentication Source is any RADIUS, LDAP, or WS-Trust server the MOVEit Transfer queries. Multiple Authentication Sources may be configured within any particular organization, and each may be of a different type (for example, two RADIUS sources and three LDAP sources) and each may reference a different template user so users already belong to the appropriate groups when they are automatically added.
The following Authentication Source types are currently supported:
Complete documentation and examples for Active Directory, Novell eDirectory, IBM Domino and iPlanet LDAP servers are provided. Other LDAP servers (such as IBM Tivoli Access Manager - SecureWay) are also supported through the use of flexible connection and attribute templates. (RADIUS server configuration is relatively generic compared to LDAP server configuration.)
Connecting to external authentication resources often requires some additional firewall rules. The various rules associated with LDAP and RADIUS services, see MOVEit Transfer Firewall Configuration.
For settings that control how MOVEit Transfer accesses external authentication sources and how new user records are configured for external authentication users, see Authentication Method section of the Settings - Security - User Policy.
For settings that control how individual users access external authentication sources, see Authentication Method section of the Users - Profile.
For information about configuring individual authentication sources, see Web Interface - Settings - Security Policies - External Authentication documentation.
There are two ways MOVEit Transfer can securely connect to on-premises LDAP sources from a DMZ segment. Both offer strong encryption of user credentials and information in transit, and neither requires anonymous access.
This scenario is quite common. First, an end user presents credentials to MOVEit Transfer over an encrypted SSH (FTP/SSH) or SSL (FTP/SSL or HTTP/S) link. MOVEit Transfer passes those credentials to the LDAP server over an encrypted SSL (LDAP/SSL) link to determine if the user can sign on to MOVEit Transfer. MOVEit Transfer does not retain the credentials in its store.
Depending how you have configured your system, MOVEit Transfer might sign on as an LDAP user with permission to browse the LDAP directory to replicate settings such as email and group membership. In this case, the credentials MOVEit Transfer uses to browse are encrypted on MOVEit Transfer using 256-bit AES.
To access an internal LDAP server directly from a DMZ-based MOVEit Transfer server, do the following:
This scenario is less common but still popular in situations where LDAP (even encrypted with SSL) is a banned protocol. First, an end user presents credentials to MOVEit Transfer over an encrypted SSH (FTP/SSH) or SSL (FTP/SSL or HTTP/S) link. MOVEit Transfer passes those credentials to a RADIUS server with encrypted RADIUS packets to determine if the user can sign in to MOVEit Transfer at that time. MOVEit Transfer does not retain the credentials in its own store. The RADIUS server (often Microsoft Internet Authentication Service, a.k.a. IAS) does not have its own user store, but is typically connected to a Windows Domain, Active Directory or other LDAP server.
The RADIUS protocol is UDP-based and all packets are encrypted with a key. This key is stored on MOVEit Transfer using 256-bit AES. MOVEit Transfer does not need to know anything about the LDAP server(s) that really holds the user information because the RADIUS server acts as a complete front end. RADIUS queries, by design, return less information about their users than a similar LDAP query.
To access an internal LDAP server securely via RADIUS from a DMZ-based MOVEit Transfer server, do the following:
Set up your RADIUS server to get authentication information from your LDAP server. (Often when using free add-on tools such as Microsoft's IAS server with Active Directory, this is your only option.)
Set up an internal firewall rule to allow MOVEit Transfer to connect to the LDAP server on UDP port 1645 (the standard port for RADIUS)
Set up an external authentication source on MOVEit Transfer. Fill in the appropriate key to encrypt RADIUS traffic for your particular RADIUS server.
People have reported that enabling SSL services on Active Directory LDAP services is harder than it ought to be. Specifically, implementing Microsoft's recommendation involving the deployment of an Enterprise Certificate Authority can take some time.
There is, however, an easier way to enable SSL on Active Directory - and it does not involve Enterprise Certificate Authority.
There is more information about this procedure on Microsoft's site, but the primary difference between Microsoft's procedure and the one laid out here is that Microsoft's recommends the use of the Microsoft certreq add-on utility in place of OpenSSL.
Finally, there are at least two alternatives to these procedures; both involve an SSL tunnel that adds SSL encryption to Active Directory's existing LDAP protocol.
Contact our support staff for more information about any of these procedures.