Provision Users from an Added LDAP Server

Use the LDAP Servers tab to add users to Reflection Gateway who have accounts in Windows Active Directory. You can use this approach to provide Transfer Site and Gateway Administrator access to Windows domain users. Authentication is managed on the LDAP server. Each time the user logs in, current information is retrieved from the LDAP server.

To configure LDAP servers, you must be a member of the Administrators group, or any group with System setup enabled.

To add access to users in an LDAP server

Log on to Gateway Administrator using an account in the Administrators group (or any account that has the System setup role enabled).
Go to System > LDAP Servers.
Click New.
Enter information for connecting to your LDAP server. For details, see New/Edit LDAP Servers Tab.

Note that the value for UserID must include the domain. For example:
```
mydomain\user
```
-or-
```
user@mydomain
```
Click Test Connection to confirm that Gateway Administrator can access your LDAP server. This test verifies the connection, but does not save your settings.
Click Save.

You can view users and groups that are brought in from an LDAP server, but cannot modify them. These users and groups must be managed on the LDAP server.

To view LDAP users and groups

Click the Users or Groups tab.
Use the LDAP server drop-down list to select your LDAP server. (If you don't see your server in the list, return to the LDAP configuration page and confirm that you saved your settings.)

NOTE:After you have added an LDAP server, you should add one or more users from this server to the Gateway Administrator Administrators group. Gateway Administrator does not support password reset for users who have access to Gateway Administrator. Adding administrators from an added LDAP server ensures that backup administrators are available to provide access if needed because these users will have full access to Reflection Gateway configuration using their Active Directory log on credentials.

Customizing the domain\username login format accepted for users in an added LDAP server

Users who have been added to the built-in ReflectionGateway list can log into the Transfer Client and/or Gateway Administrator using just a user ID (for example joe) or using the domain name and user ID (ReflectionGateway\joe).

When users log in using an account in an added LDAP server, authentication is handled by the LDAP server. The login requirements in this case depend on the LDAP server requirements and how you have configured the added LDAP server in Gateway Administrator. You can use Advanced domain settings on the New/Edit LDAP Server page to customize how Reflection Gateway sends user credentials to the LDAP server. For example, you can use Advanced domain settings to specify a default domain name so that users do not need to include the domain name when they log in even if this is required by the LDAP server.

NOTE:

Reflection Gateway searches all available LDAP servers for a matching user and authenticates the first matching user it finds; it does not search additional LDAP servers if that fails.
When no domain name is included, a UserID for a different domain could match and allow login if the passwords for both accounts are the same.
Advanced domain settings apply to password authentication only; X.509 certificate authentication always requires user mapping that specifies both a domain and username.

These examples use acme as a sample Active Directory domain. For these examples, this acme is a domain that requires a valid authentication domain name. It can accept both acme and acme.com as the authentication domain name.

Example 1

Domain Name = anyName; Domain Mapping = anyAlias; Remove User Domain= No, Default Authentication Domain = none.

Login as validUser: Authentication fails because there is no authentication domain name, and this is required by the acme domain.
Login as anyName\validUser or anyAlias\validUser: Authentication fails because anyName and anyAlias are not valid authentication domain names.
Login as acme\validUser or acme.com\validUser: Authentication succeeds because acme and acme.com are valid authentication domain names.

Example 2

Domain Name = anyName; Domain Mapping = anyAlias; Remove User Domain = No, Default Authentication Domain = acme.

Login as validUser: Authentication succeeds because Reflection Gateway adds the value specified for Default Authentication Domain (acme) before authenticating the user.
Login as anyName\validUser or anyAlias\validUser: Authentication fails because anyName and anyAlias are not valid authentication domain names.
Login as acme\validUser or acme.com\validUser: Authentication succeeds because acme and acme.com are valid authentication domain names.

Example 3

Domain Name = anyName; Domain Mapping = anyAlias; Remove User Domain= Yes, Default Authentication Domain = none.

The following results are based on the sample acme domain, which requires a valid domain name for authentication:

Login as validUser: Authentication fails because there is no authentication domain name, and this is required by the acme domain.
Login as acme\validUser: Authentication fails. Although acme is the valid authentication domain name, it is removed before Reflection Gateway attempts authentication.
Login as anyAlias\validUser or anyName\validUser: Authentication fails because authentication is attempted with no authentication domain name.

If your Active Directory domain does not require an authentication domain, the login attempts above will succeed because each of them presents a valid user ID to the domain. In this case, using anyAlias\validUser improves performance because the Domain Mapping directs Reflection Gateway to authentication to this specific LDAP server. Although anyAlias is not the actual domain authentication name, authentication succeeds because the domain name is removed before Reflection Gateway attempts authentication.

Example 4

This example shows a configuration for handling a merger that brings users from the summit domain into the acme domain. It enables summit users to log in without modifying their familiar credentials.

Domain Name = acme; Domain Mapping = summit; Remove User Domain= Yes, Default Authentication Domain = acme.

Login as validUser: Authentication succeeds because Reflection Gateway uses the value specified for Default Authentication Domain (acme).
Login as acme\validUser or summit\validUser: Authentication succeeds because the entered domain, acme or summit, is removed and default acme is used.
Login as anything\validUser: Authentication succeeds. A domain is provided by the user for which no mappings exist. In this case Reflection Gateway tries all configured LDAP servers and applies the directory-specific domain rules for each one. Authentication to the acme domain will succeed because the entered domain anything is removed and replaced by acme.