|
|
|
|
|
MOVEit DMZ provides the ability to authenticate users to external LDAP and/or RADIUS servers. Microsoft Active Directory (AD) operates as an LDAP server, so MOVEit DMZ can authenticate to it natively. MOVEit DMZ can also authenticate users against ODBC-compliant databases through the use of the optional RADIUS-ODBC authentication service. Both of these transports can be secured at the transport level (we encourage the use of LDAP over SSL) and related credentials are stored encrypted on MOVEit DMZ.
In addition to authenticating existing users against external sources, MOVEit DMZ has the ability to create new users, often as a clone of an existing template user. MOVEit DMZ also has the ability to split an organization's user base into External Users and Internal Users with one group using an external authentication source and the other using MOVEit DMZ's built-in user database. When accessing an LDAP server, MOVEit DMZ has the ability to replicate group membership information and information such as email address from that LDAP server as well.
In enterprise environments, an externally authenticated MOVEit DMZ site can participate in Single Signon (SSO) arrangements in two different ways:
An Authentication Source is any RADIUS or LDAP server the MOVEit DMZ queries. Multiple Authentication Sources may be configured within any particular organization, and each may be of a different type (e.g., 2 RADIUS sources and 3 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 are covered in MOVEit DMZ Firewall Configuration.
The settings which control how MOVEit DMZ accesses external authentication sources and how new user records are configured for external authentication users are covered in Authentication Method section of the Settings - Security - User Policy.
The settings which control how individual users access external authentication sources are covered in Authentication Method section of the Users - Profile.
Information about configuring individual authentication sources can be found in the Web Interface - Settings - Security Policies - External Authentication documentation.
Complete information about the optional RADIUS-ODBC authentication service can be found in Advanced Topics - RADIUS-ODBC Authentication. More information about SiteMinder SSO integration is available in Advanced Topics - SiteMinder Integration.
There are two ways MOVEit DMZ can securely connect to internal 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 his or her credentials to MOVEit DMZ over an encrypted SSH (FTP/SSH) or SSL (FTP/SSL or HTTP/S) link. MOVEit DMZ turns around and passes those credentials to the LDAP server over an encrypted SSL (LDAP/SSL) link to figure out if that user may sign on to MOVEit DMZ at that time. MOVEit DMZ does not retain the credentials in its own store.
Depending how you have configured your system, MOVEit DMZ may 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 DMZ uses to browse are encrypted on MOVEit DMZ using 256-bit AES.
To access an internal LDAP server directly from a DMZ-based MOVEit DMZ server, there are several steps to take:
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 his or her credentials to MOVEit DMZ over an encrypted SSH (FTP/SSH) or SSL (FTP/SSL or HTTP/S) link. MOVEit DMZ turns around and passes those credentials to a RADIUS server with encrypted RADIUS packets to figure out if that user may sign on to MOVEit DMZ at that time. MOVEit DMZ does not retain the credentials in its own store. The RADIUS server (often Microsoft Internet Authentication Service, a.k.a. IAS) doesn't really have a user store of its own, but instead is usually tied into 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 DMZ using 256-bit AES. MOVEit DMZ does not need to know anything about the LDAP server(s) that really hold the user information because the RADIUS server acts as a complete front end. (Some sites have commented that they enjoy the fact that RADIUS queries, by design, return less information about their users than a similar LDAP query would.)
To access an internal LDAP server securely via RADIUS from a DMZ-based MOVEit DMZ server, there are several steps to take:
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 DMZ to connect to the LDAP server on UDP port 1645 (the standard port for RADIUS)
Set up an external authentication source on MOVEit DMZ. 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 Microsoft's 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.