Authentication Service

Overview

The administration page to set the Authentication Service of FMR has controls for the different security services. Use the drop-down at the top of the page to select the service you require. The current options are:

• None
• Active Directory
• LDAP
• Fusion Security

Configuring Active Directory

When Active Directory has been chosen as the Authentication Mechanism, the following information needs to be provided

• The protocol type: either ldap or ldaps
• The IP address or name of the server hosting the Active Directory instance
• The Active Directory Domain Name - this can be obtained from the Active Directory administration tool
• The Base Group Domain Name (optional) - if this is left blank, the root of the Active Directory instance will be used to locate users
• The User Search Filter (optional)

The 2 values which are sometimes the most difficult to define are the Base Group Domain Name and the User Search Filter. If these are specified incorrectly, then even though FMR is communicating with your Active Directory instance correctly, then you may find users are unable to login.

User Search Filter

This field determines how the FMR will locate users within the AD tree. The syntax of valid values can be located on the Microsoft support site. FMR will not validate the contents of this field for syntactical correctness and will simply use what is entered.

If this field is left blank, the following value will be used:

(&(objectClass=user)(userPrincipalName={0}))

This states that the search filter is looking for objects in Active Directory of class "user" and where the User Principal Name of those objects is the value as specified by {0}. {0} is a placeholder for the value the user types in to FMR in order to become authenticated, however there are some subtleties. In the User Search field there are two placeholder values:

• {0} - is the "bind principal". This is the username that the user types into the login dialog (when attempting to login). However if this value does NOT contain an "@", then the domain name is appended to it. For example, if the user attempts to log in as "Alice", on the domain "bisorg.external", then the value that replaces {0} will be Alice@bisorg.external
• {1} - is the "username" only. This corresponds exactly to the username. If the user attempts to log in as "Alice", then the value that replaces {1} will be simply "Alice".

By way of example, the following specifies a search for objects of class "user" where the User Principal Name in AD will be the "bind principal". If this is not resolved, then the sAMAccountName is checked against the username:

(&(objectClass=user)(|(userPrincipalName={0})(sAMAccountName={1})))

Testing the Active Directory Settings

Since it can be difficult to set the Active Directory settings correctly, since version 11.16.1 of FMR, there is also the ability from this page for an Admin user of FMR to test how Active Directory would respond with an attempted log-on for a particular user. This feature allows for quicker investigation and resolution of the Active Directory settings that you will require for your environment.

Other Active Directory Tools

If you are still struggling to determine what your settings should be for Active Directory, then the Windows Powershell commands "Get-ADUser" and "dsquery" may be useful to you.

When run from a Windows PowerShell that is capable of communicating with the underlying Active Directory, dsquery allows you to test your search filter, such as in the following manner, which attempts to get the XXX for the user 'test1'

dsquery * domainroot -filter "(&(objectClass=user)(userPrincipalName=test1*))"

"CN=test1,OU=users,OU=Registry,OU=fusion,DC=bisorg,DC=external"