MicroStrategy ONE
Troubleshooting LDAP Authentication
LDAP authentication problems in Intelligence Server usually fall into one of these categories:
- Authentication issues that include clear text and Secure Socket Layer (SSL) connection modes
- Functionality problems/questions about importing users or groups, and synchronizing LDAP users in the MicroStrategy metadata
LDAP Set Up Problems
The following list describes error messages that may in MicroStrategy when trying to connect to the LDAP Server.
- Missing components: If you receive an error message stating that LDAP components could not be found, it may mean the DLL files are not in the appropriate directory. For details on choosing the correct DLL files according to your SDK and installing them in the correct location, see Implement LDAP Authentication. If you move your DLL files, be sure to restart Intelligence Server.
- Invalid login/password: If you receive an "Incorrect login/password" error message, check your login name and password carefully. Also check that you have the correct DN search root and the correct user search filter syntax in the Intelligence Server Configuration Editor.
- Cannot contact LDAP Server: If you receive a "Cannot connect to the LDAP Server" error message, try to connect using the LDAP Server IP address. You should also check to be sure the LDAP machine is running. Another possibility is that the SSL certificate files are not valid. For additional SSL troubleshooting, see the next section.
LDAP Connection Mode Problems
The authentication process involves an authentication user which contacts the LDAP Server, and the actual user who is logging in. The authentication user is used by Intelligence Server to log in to the LDAP server and search for the actual user, using the actual user's Distinguished Name (DN). Therefore, the authentication user must have the necessary read and search privileges within the LDAP server and must be able to log in to a correct root. A correct root is characterized as one that contains each of the potential LDAP users who will be logging to Intelligence Server in one of its branches. Thus, if the authentication user cannot find the actual user in one of its branches, the search for the actual user fails.
There are two modes of connecting to your LDAP server: Clear Text and SSL. Depending on which you are using, answering the following questions may help you reach a solution:
- If authentication fails in clear text mode:
- Can the authentication user log in as an LDAP user? The authentication user string can be tested in Developer using the Test Connection option in the Intelligence Server Configuration Editor. You can also test the user connection to the LDAP Server using any LDAP browser.
- Is the authentication DN string correct?
- Is the password for the authentication user correct?
- Can the LDAP user (different from the authentication user) log in? You can test this with any LDAP browser.
- Are the user credentials correct?
- Do the LDAP server-side logs show success messages? The LDAP administrator can access these logs.
- If authentication fails in SSL mode:
- Does the authentication work in clear text mode?
- Are the LDAP-SDK dlls installed on the Intelligence Server machine?
- Do the LDAP-SDK dlls reside in the correct system path?
- Is the certificate obtained from the correct Certificate Authority (CA)? (For information on how to obtain the certificate from the corresponding CA platforms, search the MicroStrategy Knowledge Base for "LDAP AND certificate AND import.")
- Does the certificate reside on the Intelligence Server machine in the correct system path?
- Do the LDAP server side logs show success messages? The LDAP administrator can access these logs.
Authentication Problems with LDAP Attributes
You can integrate LDAP attributes in your MicroStrategy security model. For example, you can import the LDAP attribute countryName
, and create a security filter that filters data by the user's country. Additionally, you can ensure that users cannot log in to projects if all required LDAP attributes are not defined, by enabling the User login fails if LDAP attribute value is not read from the LDAP server option.
If you select the option to prevent users from logging in if their LDAP attributes are not defined, be aware of the following potential issues:
- This setting prevents users from logging in to all projects in a project source.
- If you are using trusted authentication, such as with SiteMinder or Tivoli, and your trusted authentication provider is configured to use an LDAP directory, this option prevents trusted authentication users if they do not have all the required LDAP attributes.
LDAP Functionality Problems/Questions
Functionality problems in MicroStrategy that are associated with LDAP authentication are most commonly caused by the integration of Intelligence Server with the LDAP servers. Once the authentication is successful (Intelligence Server has verified the existence of the LDAP user in the LDAP server), it needs to treat the LDAP user as a MicroStrategy user so that the user has the necessary privileges. (Note that privileges depend on how the LDAP user is authenticated. See Implement LDAP Authentication for more details.)
Intelligence Server achieves this transformation by importing the LDAP user as a new MicroStrategy user into the MicroStrategy metadata (the option not to import the LDAP user is discussed later). The relationship between the LDAP user and the MicroStrategy user is maintained using a link in the MicroStrategy metadata, which is in the form of a Distinguished Name (DN) specified for the user. A DN is the unique identifier of an entry in the LDAP directory.
You can choose to assign DNs to MicroStrategy users explicitly. If none is supplied, the LDAP user's DN is assigned to the MicroStrategy user after the LDAP user is imported. MicroStrategy uses the DN to locate users and groups in the LDAP Server even if LDAP users and groups are configured to be authenticated in MicroStrategy other than via import.
The MicroStrategy user's DN is different from the DN assigned for the authentication under LDAP configuration. The authentication user DN is the DN of the MicroStrategy account that logs in to the LDAP server and does the authentication (search/verification) for the actual user trying to log in. The authentication user can be anyone who has search privileges in the LDAP Server and is generally the LDAP administrator.
The authentication user DN is specified in the Intelligence Server Configuration Editor, in the LDAP: Server category, in the Distinguished Name (DN) field under Authentication User.
The user's DN is specified on the User Editor in the Authentication: Metadata category in the Distinguished Name (DN) box under LDAP Authentication.
If no explicit link is specified, the LDAP user is imported as a new MicroStrategy user under the LDAP Users
group if the Import Users check box is selected. The user can then be treated as any MicroStrategy user and assigned privileges. The user object in the metadata for the MicroStrategy user now also contains a link to the LDAP user after the import.
Intelligence Server also allows LDAP groups to be imported. With this option selected, all the groups to which the user belongs are also imported under the LDAP Users
group (similar to the imported user) when an LDAP user logs in.
You cannot link MicroStrategy system groups (such as the Everyone group) to an LDAP group.
The hierarchical visual relationship between users and their user group is not maintained in the LDAP Users
folder because it is maintained in the LDAP server directory. In spite of the visual link not appearing, the actual link between the user and their group does exist and is maintained.
The Synchronize at Login options for both users and groups cause Intelligence Server to check (at the time of next login) whether:
- MicroStrategy user information in the metadata and the LDAP user information in the LDAP Server are synchronous
- MicroStrategy group information in the metadata and LDAP group information in the LDAP Server are synchronous
The names and links between the two may or may not be synchronized depending on whether the synchronize option is selected in combination with whether users and groups are to be imported.
When the user is logged in as a non-imported LDAP user:
- The logged in LDAP user has the privileges of the MicroStrategy LDAP user group and the MicroStrategy Everyone group.
- The non-imported user does not have an Inbox, because the user is not physically present in the metadata.
- The non-imported user cannot create objects and cannot schedule reports.
LDAP Frequently Asked Questions
Do LDAP users have their own inbox and personal folders?
If users are imported into the metadata, they have their own Inbox and personal folders. If users are not imported, regardless of whether they are part of the LDAP Users or LDAP Public group, they do not have an Inbox. Users that are not imported do not have personal folders and can save items only in public folders if they have the correct privileges and permissions.
How can I assign security filters, security roles (privileges), or access control (permissions) to individual LDAP users?
Security filters, security roles, and access control may be assigned to users after they are imported into the MicroStrategy metadata, but this information may not be assigned dynamically from information in the LDAP repository.
To allow users to dynamically inherit this information, you should assign these permissions at the group level in the MicroStrategy metadata. Group membership information is dynamically determined each time an LDAP user logs into the system, according to the group they become part of.
May two different users have different LDAP links, but the same user name?
Yes. The MicroStrategy metadata may contain two users with the same user name as long as the login name is different. For example, one employee can use jsmith as their login name, and the other can use johnsmith as their login name. With these unique login names, each user can use John Smith as their user name.
What happens if there are two users with similar descriptions in the LDAP directory?
If the DN descriptor that specifies a user is not sufficient for Intelligence Server to identify them, the user will fail to log in. You should enhance the User search filter and Group search filter in the LDAP configuration category to help identify the user.