Since FusionReactor 8.2, users with Enterprise licenses (or better) can use Microsoft Active Directory to log in to FusionReactor. In this blog post, we’ll cover how to set this up.
In FusionReactor 8.2, we changed the way we handle logging you in and out behind the scenes. We still have the Role/Password system, and it’s still the basis of the authentication system, but we’re now able to provide other ways to authenticate you. The first new authentication scheme we added in 8.2 is the Lightweight Directory Access Protocol, or LDAP. LDAP is used by large organizations to enable their users to log in to different systems, without having to set these users up on each and every system. There are several Directory Service products that are LDAP-enabled – and can therefore be used by FusionReactor – and Microsoft’s Active Directory system is an important and popular one. Setting up Active Directory itself is a long and quite complicated process, and isn’t covered by this post. We’ll assume you have a working Active Directory environment already.
Here’s what you’ll need to have before you start configuration FusionReactor. Your Active Directory administrator will be able to supply this information.
You’ll need to find out: You’ll additionally need to have a strategy for mapping your Active Directory users to FusionReactor roles: Administrator, Manager, and Observer. Any roles you don’t have mappings for will be simply disabled – users won’t be able to log in to these roles. One common strategy is to set up a new Active Directory User Group for each of the FusionReactor roles. You’ll need the Distinguished Name (DN) of the groups you’re going to use for these users. You can get this information in Command Prompt using the command There are some additional prerequisites and rules for mapping users, and these are detailed in our User Manual. Here are the details we’re using for our example: Now we can go ahead and configure FusionReactor.
Navigate to FusionReactor > Manage Logins > FusionReactor X.500/LDAP Login to access the LDAP configuration section.
Many user interface elements can be configured for this login mechanism. We’ve set up some example data so you can see how it maps to the actual login screen. Here’s the configuration:
… and here’s the rendered login screen:
Here’s the configuration for the remaining details:
The Test Login button can be used to check these details are right. FusionReactor will try to log in to Active Directory using these details. Now we’ll enter the filter for the Administrator user. Don’t worry about the syntax yet, we’ll cover that next. Any users matched by this filter in Active Directory will be able to log in as FusionReactor Administrator.
The Validate Filters button checks the syntax of the filters. Finally we hit Save Login Settings to save this form. To make LDAP the preferred login provider, go to FusionReactor > Manage Logins > Global Settings and set FusionReactor X.500/LDAP Login as the Preferred Identity Provider. Now let’s have a look at the filter.
The filter we used to identify Administrators is as follows (we’ve formatted it so it’s easier to read). LDAP filters are very powerful (more information). Here’s a breakdown of this one:
The ability to log in to any LDAP-enabled service opens up FusionReactor authentication to a whole new realm of Enterprise possibility. Active Directory is perhaps the most popular service for handling thousands of users, and FusionReactor’s LDAP interface allows these users to access FusionReactor without having to share a role password.Using Active Directory to Log In to FusionReactor
Introduction
Prerequisites and Required Information
Prerequisites
Required Information
You can find this by running the following command in Command Prompt on your Active Directory server:dsquery * -scope base
You can use the following command in Command Prompt to list all users:dsquery user
dsquery group
.
1.2.3.4 / 389
DC=testdomain,DC=com
CN=FusionReactor LDAP Reader,CN=Users,DC=testdomain,DC=com
fusion4u
fradmins
.Configuration FusionReactor
UI Elements
Active Directory Server Details
Crafting LDAP Filters
(& (objectClass=user) (sAMAccountName={{USERID}}) (memberof=CN=fradmins,CN=Users,DC=testdomain,DC=com) )
objectClass=user
ensures that the filter only matches users. Active Directory can also store information about computers, printers and other resources. We are only interested in users.sAMAccountName={{USERID}}
means that whatever the user provides in the upper login input box (which we labelled Active Directory Username earlier) will be used to select an Active Directory record with that value as the Windows Logon ID (what Active Directory calls the SAM Account Name).memberof=CN=fradmins,CN=Users,DC=testdomain,DC=com
means that the user must be part of an Active Directory group called fradmins.Conclusion