LDAP stands for Lightweight Directory Access Protocol. It is an application protocol used to manage and access the directory service.
Every email program has a personal address book, but how can we look up an address for someone who’s never sent you email? How can an organization keep one centralized up-to-date phone book that everybody has access to?
Those questions led a group of companies to support a standard called LDAP. “LDAP-aware” client programs can ask LDAP servers to look up entries in a wide variety of ways. For example, an LDAP search translated into plain English could look like this: “Search for all people located in New York whose name contains ‘John’ that have an email address and return their full name, email and title.” Handy, right?
Directory service is a shared information infrastructure for locating, managing, administering and organizing everyday items and network resources, which can include users, groups, printers, folders, files, devices and other objects. If a directory service is LDAP enabled, applications can use LDAP protocol to “talk” to it.
Active Directory (AD) is Microsoft’s proprietary directory service solution developed for Windows OS. We’ll be using AD as our directory service in this blog post.
There can be some confusion in differentiating between AD and LDAP because sometimes the terms are used interchangeably. The relationship between AD and LDAP is much like the relationship between Apache and HTTP:
One of the most important AD concept to understand is domain. Basically, a domain is a container for objects (computers, users, devices, etc.) and is identified by its DNS name structure, like example.com.
Let’s take a look at how things are organized inside an individual domain such as example.com in our example below. We’ll use the example.com domain throughout the blog post.
Example of a directory service tree
Distinguished Name (DN) of a directory entry is the unique name that identifies it. The Distinguished name is composed of attribute=value pairs separated by commas. Those attributes are usually Domain Component (DC), Organizational Unit (OU), and Common Name (CN). This is the way we’ll identify Active Directory entries in MicroStrategy.
That being said, Distinguished Name of our example John Doe user is:
‘Ldap service’ is a kind of a service account that will be used as an authentication user. More about that later.
With theory out of the way, it’s time to get our hands dirty.
We can connect LDAP server to Microstrategy Intelligence server using LDAP connectivity wizard or by filling out the LDAP category of the Intelligence Server Configuration Editor. We’ll use the latter approach.
There are two ways we can link MicroStrategy users with their LDAP counterparts. One is to import them directly into MicroStrategy from LDAP repository, and the other is to link already existing MicroStrategy users with their corresponding LDAP users. In this blog we’ll follow the latter approach since it’s better suited to linking small amount of MicroStrategy users to their LDAP accounts.
We’ll use data from an example.com domain. Let’s start with the setup.
Right click Project Source, then Configure MicroStrategy Intelligence Server, then LDAP category. You’ll be greeted with the following screen:
LDAP authentication setup part 1
Naturally, the text boxes will be empty, it is our job to enter the correct information. We will enter the following:
Authentication User is an important concept and needs further explanation. When an LDAP user logs into MicroStrategy Web or Developer, Intelligence Server connects to the LDAP server using the credentials for the LDAP administrative user, called an Authentication User. The authentication user is bound to LDAP using a Distinguished Name (DN) and password that we just set up in Authentication User text boxes. The Authentication User searches the LDAP directory for the user who is logging in via Developer or MicroStrategy Web, based on the DN of the user logging in. If this search successfully locates the user who is logging in, the user’s LDAP group information is retrieved, and with some intermediary steps in between, the user who is logging in is given access to MicroStrategy.
That being said, the Authentication User must be set up (must exist) in the LDAP repository before configuring LDAP settings in MicroStrategy. The user must have, at a minimum, read and search access rights to the required user and group objects. Best practice is to use a ‘dummy service account’ specifically created for that purpose, not an actual user account.
In our case we entered the following information in Distinguished name (DN) text box: CN=ldap service,CN=Users,DC=example,DC=com
LDAP authentication setup part 2
This part is pretty straightforward and self-explanatory. LDAP server vendor name is Microsoft Active Directory, the same is true for LDAP Connectivity Driver. The OS where Intelligence Server is installed is Windows Server 2012, so we pick Windows. LDAP connectivity file names area is automatically populated with WLdap32.dll.
Data flow in LDAP enabled MicroStrategy environment
Here we can provide information to narrow down the user and group searches of our LDAP server.
LDAP authentication setup part 3
Search root distinguished name (DN): Provide the root DN to establish the directory location from where in the LDAP tree to start any user and group searches. By default, this field is empty. If a root DN is not provided, Intelligence Server searches the entire LDAP tree. You can think of the root DN as the highest level in the LDAP tree where the search can reach. The image below represents the section of the LDAP tree that the search accesses, represented as the distinguished name nodes with solid blue lines. The distinguished name nodes with dashed grey lines are not included in the search since they are not under the search root distinguished name.
Difference between LDAP Tree Root and Search Root
In our case, Search Root is ‘Developers’ Organizational Unit so we entered it’s Distinguished Name.
User search filter and Group search filter: Here we have user and group filters to further narrow down the amount of users or groups. Default information appears automatically based on the vendor name provided in the Platform Connectivity step of this wizard. We will leave it as is.
Test Connection: Here we can test the connection with LDAP server. After clicking Test Connection, a window is displayed where we can enter the credentials of the user we want to test the connection for.
We can disregard Schedules and Import categories. These are the options we would play with if we were to import users directly from LDAP, which we will not be doing.
Now we will enable LDAP authentication on MicroStrategy server side so users can actually login using LDAP credentials.
To do that for MicroStrategy Developer users, right click project source, then Modify Project Source, and finally choose Advanced card. Pick Use LDAP Authentication radio button.
Enabling LDAP Authentication for Developer users
To enable LDAP Authentication for Web users, open Web Administrator console, pick Default properties category and check the LDAP Authentication checkbox. If you want you can also check LDAP Authentication radio button for it to be a default login option for Web users.
Enabling LDAP Authentication for Web users
Well, the setup is now done from the server side! Now the only thing that’s left is actually linking MicroStrategy users with their Active Directory counterparts. To achieve that, we have to edit individual MicroStrategy user objects and provide them with their LDAP counterpart distinguished names. In that way the metadata will know which MicroStrategy users to link with which Active Directory user.
As an example we’ll take our John Doe. Of course, there is John Doe user present in Active Directory and John Doe user object present in MicroStrategy. We just need to tell MicroStrategy that they are actually the same user.
Linking up MicroStrategy users with their AD counterparts
To do that we’ll go to Administration, then User Manager, and find our John Doe. Then, we’ll open the User Editor and go to Metadata subcategory.
Here we need to enter the following:
And that’s it! Now we can use John Doe’s LDAP credentials to login into MicroStrategy. To try that out, open MicroStrategy Web (or Developer) and type in your domain (Active Directory) credentials. In our case that is jdoe, along with domain password.
Entering our credentials…
After entering the credentials, we successfully accessed the Tutorial project.
Since Active Directory is such a big part of enterprise environments, why not leverage it?
We just scratched the surface of LDAP integration with MicroStrategy. There are many more advanced features that are not in the scope of this blog series, such as using LDAP attributes in security filters, or using LDAP credentials for authentication against the DBMS when running reports (database passthrough).
Hopefully, this blog series showed how simple it is to integrate LDAP authentication within MicroStrategy and maybe even encouraged some of you to try it or consider it as a possible solution.
That’s all folks!