Authentication Service

From FMR Knowledge Base
Revision as of 05:47, 10 May 2024 by Plazarou (talk | contribs) (Testing the Active Directory Settings)
Jump to navigation Jump to search

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

Authentication Set-up

  • 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)
  • 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.

Base Group Domain Name

The value here can be left blank, in which case the root of the Active Directory tree will be used as the root of searching for users. However to be more specific you can specify the Organizational Units (OU) and Domain Components (DC) to search within. It is likely you will need to specify the Domain Components. Please note that the order of the components is very important here.

When specifying OUs they are typically listed in reverse order, with the lowest-level OU specified first which aligns with the hierarchical nature of how these units are defined within AD. The DC elements are listed in a more natural left-to-right order.

By way of example, if you wished to search in the Domain Component "bisorg.external" and under that domain, there was the hierarchy of the Organizational Unit "fusion" with the Organizational Unit "Registry" within that, then the following string, with its elements in the following order, would be used:

OU=Registry,OU=fusion,DC=bisorg,DC=external

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.

Clicking the "Test Settings" control displays a section of the page allowing the systems admin to enter a userid and password. Note that the other AD settings can be modified during this time allowing for experimentation.

When "Test User" is clicked , the system attempts to authenticate the user specified in the lower section. Here are some sample responses:

Example of incorrect password for the user: <XXX>

Example of incorrect AD - the user couldn't be located since the Base Group DN was incorrect: <XXX>

Example of too many users being found. There must be a unique user for the specified userid <XXX>

Example of correct credentials: <XXX>

Other Active Directory Tools

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

dsquery is a command-line tool in Windows operating systems used to query the Active Directory directory service. Active Directory is a service developed by Microsoft that provides centralized authentication, authorization, and directory services for Windows-based networks. The dsquery command allows administrators to search and retrieve information from Active Directory. It can be used to find various objects such as users, groups, computers, and organizational units (OU).

If you wish to find a particular user, you can use the command:

    dsquery user -samid <username>

It can also allow you to test your search filter, such as in the following manner, which obtains the Base Group DN for the user 'test1'

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

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


The Windows PowerShell command Get-ADUser allows the retrieval of a user's information. So to see what the sAMAccountName is for a particular user, you can use:

    Get-ADUser -Identity "username" | Select-Object SamAccountName

Next Steps

It is likely that you will wish to create Role Mappings for your users. Please refer to the Role Mappings page for further information.