The Lookup + Authentication mode for LDAP authentication offers much more flexibility than the Authentication Only mode. When this mode is set, DMZ will query the LDAP server for information about the incoming user and then use that information to build a login string. This querying allows DMZ to authenticate users from several different organizational units or domains. It also allows DMZ to use fields from the user's LDAP entry when building new user accounts, and even allows group memberships to be synchronized between the LDAP server and DMZ.
The Edit LDAP Authentication Settings section determines the primary and backup server URL, administrator login and password, and login template to be used for this source. The primary URL and login template are required to be present. All other fields are optional.
In addition to the base LDAP URL, the Path setting should also be provided with the base LDAP path in which users should be searched for. For example, if only users in the FileTransfer organizational unit should be allowed to sign on to DMZ, the path might be set to "LDAPS://server.company.com/ou=FileTransfer,dc=server,dc=company,dc=com". The use of "LDAP://..." vs. "LDAPS://..." determines whether or not LDAP over SSL will be used. (The use of LDAP over SSL is encouraged to protect the transmission of credentials and other user information between MOVEit DMZ and any LDAP servers.)
Macros can be used in the Login Template to construct the appropriate login string for the user. Any field in the LDAP user entry can be used by simply surrounding the field name with square brackets ([]). For example, if you wish to use the value of the LDAP field "distinguishedName" for the user's login string, simply set the Login Template setting to "[distinguishedName]". The special macro "[mi:dn]" will be interpreted by DMZ to be the LDAP distinguished name of the user.
The Administrator Login String and Password settings determine the account that DMZ will use to login to the LDAP server to find information about incoming users. It is also the account that will be used by the overnight scheduler to synchronize user information between DMZ and the LDAP server.
As with the Authentication Only mode, the Max Retries setting is also available. Max Retries determines how many additional times the authentication source will be queried if a query has an error. This setting only applies to the authentication of the user, not the querying for user information.
Finally, both the primary and backup LDAP server sections have "Test Connection" links which can be used to test the authentication settings. Clicking either link will open the LDAP Connection Test Results window, which will list the parameters of the test, the result of the test, and any diagnostic information collected during the test.
The Edit LDAP User Settings section determines how a user authenticated by this source will be handled. In addition to determining the values used to create new users, many of the various templates are also used during subsequent signons, and by the nightly LDAP synchronization task to make sure the user account remains synced with the user's LDAP entry.
As with the Authentication Only mode, the Auto-Create Account on Signon setting determines whether a new user will be automatically added to DMZ when they successfully authenticate. The Auto-Create Account in Scheduler setting determines whether users who exist on the LDAP server but not on DMZ will be automatically added as well.
The Expire Account When No Longer Authorized setting allows users who were previously authorized by the LDAP server to be marked as expired if they are no longer allowed to sign on, either because they have been removed from the LDAP server, or no longer allowed by the Group Check Mask rule. Once a user has been expired, they will be deleted from the organization after seven days, unless the user becomes re-authorized on the LDAP server or an administrator manually changes the user's status.
The User Object Class and Username Field settings define the searches that DMZ will execute against the LDAP server both during user signons and during the nightly scheduled task. User Object Class indicates the value of the objectClass property that indicates an LDAP entry is a user. The Username Field indicates the name of the field that will contain the username of the user entry.
The User Object Class setting can also be used to perform more advanced LDAP queries. This can be useful in cases such as with Active Directory, where computers in the directory are also considered users. In order to only return true user accounts, a more advanced query is needed to get all objects with objectClass=user, but avoid those objects which also have objectClass=computer. This more advanced query can be put in the User Object Class setting, and the system will correctly interpret and execute it. For the above example, the User Object Class should be:
(&(!(objectClass=computer))(objectClass=user))
The Fullname, Email, Home Folder, and Notes template fields determine what values will be used for newly created users, and for synchronizing existing users. These template fields can use macros of any field in the LDAP user entry. The MOVEit DMZ specific macro "[mi: userid]" can be used in the Home Folder template to indicate the use of the MOVEit DMZ user ID for creating the user's home folder. Again, as with the Authentication Only mode, the Default Authentication Method setting determines whether newly created users will authenticate using both the external authentication sources and MOVEit DMZ's internal database, or just the external sources. Note that all four fields will be used when creating a user, but only the Fullname and Email fields will be used when synchronizing a user.
Note that with the Email template field, you can select Ignore blank Email fields in LDAP source to ensure that blank email addresses on the LDAP source will not be synchronized to MOVEit DMZ user settings. This will prevent any existing email entries in MOVEit DMZ from being overwritten with the blank entry from LDAP.
The Client Cert Field setting defines the LDAP field that contains client certificates in the user entry. If this setting is set to a non-blank value, DMZ will consider the LDAP server to be the authoritative client certificate repository, meaning any client certificates added manually through the web interface will be overwritten by whatever value is in the LDAP server. If client certificates are to be managed outside of the LDAP server, this field should be left blank.
If the value is not blank, client certificates found in the matching LDAP field will be added to DMZ's internal client certificate store so that they can be used for identification and authentication purposes. All listed certificates in the user's LDAP entry will be synchronized to DMZ's internal store.
Supported client certificate types are DER-encoded X.509 and Base64-encoded X.509 certificates. Other types will not be processed by MOVEit DMZ.
NOTE: Self-signed client certificates stored in DMZ's internal store will not be added to the Microsoft Trusted Root Store on the server during LDAP synchronization. This means that they will not be usable as an authentication method for MOVEit DMZ without manual intervention. For this reason, when using LDAP-stored client certificates with MOVEit DMZ, only use certificates that have been signed by a trusted CA certificate.
The "Test LDAP Search" link can be used to test the user settings to ensure that they are correct for locating user accounts on the LDAP directory. Clicking the link will open the Advanced LDAP Search Test Results window, which will list the parameters of the test, the result of the test, and any diagnostic information collected during the test.
These settings allow DMZ to more easily find a user's record in LDAP when provided only with a client certificate. They are only available if the Allow Username from Client Certificate setting is enabled on the Default HTTP Policy Settings page. See the Security Policies - Interface page for more details.
When the Allow Username from Client Certificate setting is enabled, users may choose to have MOVEit DMZ automatically detect their username based on the client certificate they provide. In addition to searching it's own internal client certificate store, DMZ can also search LDAP external authentication sources, if any are available and have the Client Certificate Field setting configured. However, since client certificates are stored in LDAP as raw data values, they cannot be effectively searched for. To avoid having to do a potentially time-consuming search of the entire LDAP user list for the correct certificate, these settings allow administrators to match a value in the provided client certificate with a searchable field in LDAP.
The Client Certificate Value setting defines a value from a provided client certificate that will be searched for in LDAP in order to find the matching user entry. Available client certificate values are:
The Matching LDAP Field setting defines the LDAP field which the chosen client certificate value should match up against when searching for the user's LDAP entry.
The Create User As Clone Of setting allows administrators to select an existing user as a template for users created by this authentication source. When this setting is enabled, the selected user will be cloned to create the new user account. If JavaScript is enabled on the browser and one or more template users exist in the organization, only template users will be shown in the dropdown menu by default. The "Show All Users" link will cause all users to be listed again. This feature is particularly useful when you want users created through the External Authentication features to have different allowed interfaces, authentication rules or permissions than users created through other interfaces.
If you plan on cloning users with preconfigured expiration policies (such as "expire after 30 days of inactivity"), you must use a "template user" (i.e. a user with a status of "template" rather than "active" or "inactive"). Cloning a template user allows MOVEit DMZ to carry an expiration policy from user to user, but template users are not themselves affected by expiration policies.
The Edit LDAP Group Settings section determines how LDAP group memberships will be handled when authenticating, creating, and syncing users. LDAP group memberships can be mirrored on DMZ based on a set of masks and mask rules. Users can be allowed or denied from signing on to DMZ based on another set of group masks and mask rules.
The Group Membership Behavior setting determines how group memberships will be dealt with. When set to "Ignore Differences", LDAP group memberships will be ignored, except in the case of the Group Check Masks setting. When set to "Report Differences", differences between DMZ group memberships and LDAP group memberships will be noted by the nightly scheduler as errors. When set to "Correct Differences", differences between DMZ group memberships and LDAP group memberships will be corrected, if possible. DMZ groups will NOT be added automatically, only group memberships. Groups existing on the LDAP server but not on DMZ will be noted by the nightly scheduler as errors.
When an LDAP group is found, its object properties will be queried by DMZ, and retrieved. These properties can then be used as macros to determine the name of the group. One or more of these macros should be placed in the Group Name Template setting to allow DMZ to determine the name of the LDAP group to match against groups on the DMZ server.
When it comes to actually finding the LDAP groups a given user is a member of, there are two available methods. The first method is by searching the user's LDAP entry for properties that denote which groups the user is a member of. This method is the default and is used when the "Search User Objects for Membership Information" option is selected.
The only setting available under this option is the User Object Group Membership Field. For each group the user is a member of, there should be one of these fields in the user's LDAP entry containing the distinguised name of the referenced group.
The second method for determining a user's group memberships is by searching the group entries on the LDAP server looking for properties that denote that the current user is a member. If your LDAP server does not provide group membership information in its user entries, this is the option you should use if you want to synchronize group memberships between LDAP and MOVEit DMZ.
There are three settings available under this option. The first is Group Object Class or LDAP Search String and is analogous to the User Object Class or LDAP Search String setting in the Edit LDAP User Settings section. This value should be set to the value of the objectClass property that indicates an LDAP entry is a group. If a more advanced query is necessary, this value can also be set to a complete LDAP query which should return group objects from the directory.
The second setting is Group Object Path. This defines the location in the LDAP directory where MOVEit DMZ should begin searching for group objects. This can be the same as the path provided in the Primary or Backup Server Path settings, or it can be different, in case those paths are set to user-specific locations.
NOTE: The Group Object Path value should not contain an LDAP host or URL. The host defined by the Primary or Backup Server Path setting will be used.
The third setting is Group Object Group Membership Field and is analogous to the User Object Group Membership Field setting under the "Search User Objects for Membership Information" option. For each user that is a member of an LDAP group, there should be one of these fields in the group's LDAP entry containing the distinguished name of the referenced user.
Finally, the Group Mask settings determine which groups will be included when syncing LDAP and DMZ group memberships. The rule can be set to include groups except those matching one or more of the masks, or ignore groups except those matching one or more of the masks. The mask list can be one or more group name masks, separated by commas. Group name masks may contain the multiple-character wildcard "*", and/or the single-character wildcard "?".
The Group Check Mask settings operate similarly to the Group Mask settings, but determine the group memberships used by the system to determine if a user should be allowed to sign on or be automatically created (or mentioned in the Scheduler error reports if the source is configured to not do auto-creation of users in the Scheduler). By default, this setting is set to allow all users regardless of group memberships. The rule can also be set to deny users except those in groups matching one or more of the masks, or to allow users except those in groups matching one or more of the masks. As with the Group Mask setting, the mask list can be one or more group name masks, separated by commas. Group name masks may contain the multiple-character wildcard "*", and/or the single-character wildcard "?".
The permission required to see properties of other users varies on each kind of LDAP server. On Active Directory server, the typical permissions required to see these properties are usually awarded to "Domain Users". With this in mind, the user credentials you configure in the "Admin Login" fields should be at least a member of this group.
While debugging authentication problems, the phrase (from the debug log)...
"SearchForUsers: filter='(&(objectClass=user)(samaccountname=freduser))'"If there is any variation (except the expected username in place of "freduser"), double-check the value you configured for Username Field in the "LDAP User" section.