LDAP
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 organisation keep one centralised 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?
Active Directory
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:
- HTTP is a web protocol.
- Apache is a web server that uses the HTTP protocol.
- LDAP is a directory services protocol.
- Active Directory is a directory server that uses the LDAP protocol.
AD Basic Concepts
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.
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), Organisational 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:
CN=John Doe,OU=Developers,DC=example,DC=com.
‘Ldap service’ is a kind of a service account that will be used as an authentication user. More about that later.
Setup and MicroStrategy Integration
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.
Step 1.
Right click Project Source, then Configure MicroStrategy Intelligence Server, then LDAP category. You’ll be greeted with the following screen:
Naturally, the text boxes will be empty, it is our job to enter the correct information. We will enter the following:
- Host: First we need to enter Server Name (or IP address) of our LDAP server. In our case the LDAP server is deployed on the same machine where Intelligence Server is, so we enter localhost.
- Port: Port number of the LDAP server. Port 389 is the default for the cleartext LDAP, and Port 636 is the default for SSL. However, check with your LDAP administrator just in case.
- Security connection: Intelligence Server can connect to the LDAP server either using clear text or by transmitting encrypted information using SSL. For demonstration purposes we’ll use clear text connection.
- Authentication method: When MicroStrategy attempts to authenticate an LDAP user logging into MicroStrategy, you can select whether to use binding to authenticate a user’s complete account information, or authenticate only a user’s name and password. By default, Password Comparison is selected and that is what we’ll use.
- **Authentication User: **Here we enter the Distinguished Name and password of an LDAP Authentication User used by Intelligence Server to access, search in and retrieve information from the LDAP directory when authenticating, importing, and synchronizing new user accounts.
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
Step 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.
Step 3.
Here we can provide information to narrow down the user and group searches of our LDAP server.
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.
In our case, Search Root is ‘Developers’ Organisational 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.
Step 4
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.
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.
Step 5
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.
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:
- **Distinguished name (DN): **Here we’ll enter the Distinguished Name of John Doe. We got that info directly from Active Directory. If you don’t have access to AD, ask your system administrator to provide the distinguished name to you. You’ll have to do this for all users you want to link with AD.
- User cannot use standard authentication to logon: check this box if you want only LDAP authentication as a login option for users. If you leave it unchecked, users will have an option to login with both standard authentication and LDAP authentication.
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.
After entering the credentials, we successfully accessed the Tutorial project.
Conclusion
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!