Submit a ticketCall us

whitepaperYour VM Perplexities Called, and They Need You to Read This.

Virtualization can give you enormous flexibility with future workloads and can be a key enabler for other areas, like cloud computing and disaster recovery. So, how can you get a handle on the performance challenges in your virtual environment and manage deployments without erasing the potential upside? Learn the four key areas you need to be focusing on to help deliver a healthy and well-performing data center.

Get your free white paper.

Home > Success Center > Database Performance Analyzer (DPA) > DPA - Knowledgebase Articles > DPA user authentication and permissions using Active Directory

DPA user authentication and permissions using Active Directory

Updated March 11th, 2016


DPA integrates with Windows Active Directory (2003 and higher) to allow domain users to login to DPA without duplicating user credentials inside of DPA.

Note: Active Directory is Microsoft's implementation of the LDAP protocol.  DPA was developed to support LDAP implementations, including Active Directory.  Therefore, you will see references to LDAP (e.g. property names that you put in the file) when AD values are needed.  

Support: At this time, only Active Directory integration is officially supported, but it will likely work with other LDAP implementations as well. OpenLDAP and Oracle Directory Server Enterprise Edition (DSEE) will work with DPA/Ignite 8.3.300 and above. If you plan on using an LDAP implementation other than Active Directory, please refer to the following article: User authentication and permissions using LDAP.

With AD authentication configured, users can log in with their domain account as well as with an DPA "custom user" account.

AD has the ability to group users, where each user can belong to multiple groups.  DPA leverages the grouping mechanism by assigning permissions to groups within DPA.  For AD, DPA specifically looks for “security groups”.

This KB article contains sections on the following:

  • Initially setting up DPA to connect to AD
  • Configuring authentication and permissions for groups of users
  • Logging in using Active Directory
  • Troubleshooting


  • DPA 9.0 - 10.1
  • Ignite 8.3.3 and later

For DPA 10.2 and later, use the configuration wizard under Options > Administration > Configure.

Initial setup

 1. Gather AD connection information:

AD server URL(s): Determine the server, full domain name, and port of your server. Typically, this looks like:

: DPA supports SSL connections to AD.  To use SSL, specify the URL using "ldaps://..." and the corresponding port. For more information regarding SSL, see "Configuring DPA with LDAP over SSL" below.

Note on port: If your environment has multiple domains, you need to configure DPA to connect to the “Global Catalog” -- typically this is done by specifying port 3268 (3269 for LDAPS).   If you are not using multiple domains, then you typically use port 389 (636 for LDAPS).

AD server failover is supported in DPA by allowing you to specify multiple URLs However, if your Active Directory is set up using “round robin”, you may only need one URL.

AD Base DN
: or top level of your directory tree:

e.g. DC=domain, DC=local

Domain Username and Password (aka Manager Account) that DPA will use to query the AD server for users and groups. Preferably, provide a user whose password does not expire.  For the username, you can use one of these formats (upper or lower case does not matter):

  • Distinguished Name (preferred): the user’s full “distinguished name” (DN)
        e.g. cn=Bob Smith,cn=Users,dc=domain,dc=local
        e.g. cn=Bob Smith,ou=Users,dc=domain,dc=com
  • User Principal Name (AD only)
        e.g. bsmith@domain.local

2. Edit DPA’s file.

dpafolder/iwc/tomcat/ignite_config/idc/   (for UNIX or Linux)

3. Add entries to the file.

If you upgraded DPA from an older version then these properties will need to be added, but if this is a new install of DPA 8.3 or higher then the entries will already exist so just uncomment them and fill in the values.  Yellow indicates connection information provided by you.

## Enable AD/LDAP

## AD/LDAP Server Info port

## AD/LDAP Manager Account (Domain User)
## This should be UPN (user principal name):
## Or the FQDN (fully qualified domain name): CN=User Name,CN=Users,DC=domain,DC=com)

## Note: plain text password will be encrypted when DPA is restarted

## Optional, only change if you are having performance problems.
## If you have a single domain and all users are in 1 folder, you
## can set this value to the folder where you would like to start
## searching (e.g. CN=Users). This may decrease the time it takes
## for DPA to authenticate a user.
## This property is relative to baseDn.

## For use with LDAPS://
## Use forward slashes for both windows and linux
## Example: Files (x86)/solarwinds/dpa/iwc/tomcatignite_config/security/dpa-truststore.jks

## If you are using a PKCS #12 (pfx) file to store your certificate, uncomment the following line:


baseDn Note: It is important that the "" property does not contain any spaces between domain components. For example:, DC=com

SSL Truststore Note: It is important that you use forward slashes "/" in the truststore path for both Windows and Unix. If you don't Java will be unable to find the file and you may see the following error in the auth.log: the trustAnchors parameter must be non-empty

The default password for is "changeit", if you are using the default, you can leave the line commented out.

4. Configuring DPA with AD over SSL:

If you wish to use AD with SSL, you will need to do the following:

  • Uncomment the and properties above and fill in the appropriate values
  • Change the to use "ldaps" and the SSL port. If you are connecting to Active Directory's Global Catalog, it is typically 3269, otherwise it is typically 636.
    • port
  • Export the LDAPS certificate from Active Directory and Import into DPA.
    • Run the DPA Certificate Importer Utility (IgniteCertImporter.jar).
      • If you are running DPA 8.3.200 or higher, the utility can be found in the following directory:
        dpafolder\iwc\tomcat\conf (for Windows)
        dpafolder/iwc/tomcat\conf (for UNIX or Linux
      • If the IgniteCertImporter.jar file does not exist in the folder listed above, it can be downloaded here: Once downloaded, unzip it in your dpafolder directory.
      • To run the application, open a command line, change to the directory where IgniteCertImporter.jar resides (ex: dpafolder/iwc/tomcat/conf) and type the following:

        java -jar IgniteCertImporter.jar

        The program will walk you through all of the steps for obtaining a certificate from your Active Directory server.

      • Skip to step 5 of the KB article and continue.

    • If for some reason the Certifcate Importer utility did not work, you can follow the steps below to manually export and import the Active Dicrectory LDAPS certificate.
      1. From the Active Directoy server, export the "Trusted Root Certificate".
      2. Use the "DER encoded binary X.509 (.CER)" format and give it a name like "client509.cer"
      3. Copy the exported certificate to the DPA server.
      4. Import the certificate into DPA's keystore. 
        • The keytool utility can be found in:
          • dpafolder\iwc\jre\bin (for Windows)
          • dpafolder/iwc/jre_linux/bin (for Linux)
          • dpafolder/iwc/jre_unix/bin (for Solaris)
        • The keystore can be found in:
          • dpafolder\iwc\tomcat\ignite_config\security\dpa-truststore.jks (for Windows)
          • dpafolder/iwc/tomcat/ignite_config/security/dpa-truststore.jks (for Linux or UNIX)
        • The import command is:
          dpafolder/iwc/jre/bin/keytool -import -keystore dpafolder/iwc/tomcat/ignite_config/security/dpa-truststore.jks -alias igniteLdaps -filepathtocertificate/client509.cer -storepass changeit
      5. You can choose any alias name you want, it will be used to manage that certificate in the keystore.
      6. Import certificates from standard Java cacerts file into DPA's keystore using keytool.
        • The import command is (the "jre" path varies for Windows, Linux and UNIX):
          dpafolder/iwc/jre/bin/keytool -importkeystore -srckeystore
          dpafolder/iwc/jre/lib/security/cacerts -destkeystore
          dpafolder/iwc/tomcat/ignite_config/security/dpa-truststore.jks -srcstorepass changeit
          -deststorepass changeit
        • If keytool asks whether to overwrite an existing enter, type "no" and press Enter to skip importing that entry.

5. Restart DPA.

 6. Verify that the connection properties are correct:

  1. Login to DPA as an administrator.
  2. Click on the Options menu link, then on the Administration tab, and finally the User Administration button.
  3. On the User Administration page, click on Add Active Directory Group.
  4. Click the “Search for a Group” button.
  5. Once the “Search for Group” dialog is displayed, type the name (or part of the name) of a group (e.g. “domain”) and then press the “Search” button.
    1. If results are returned, then AD is configured correctly, see below for configuring authentication groups.
    2. If an error occurs when attempting to search, double check your configuration values in If you are certain that you have configured the properties correctly, you can check the dpafolder\iwc\tomcat\logs\auth.log file for more information.

If you require assistance, open a technical support ticket at

Configure authentication and permissions for groups of users

After you have set up DPA to use AD/LDAP, do the following:

  1. In AD, determine which group(s) contain the users that you wish to grant access to DPA.  You may need to create a group if a suitable group does not exist.
  2. In DPA, click on the Options menu, then the Administration tab, and then click User Administration.
  3. Click Add Active Directory Group.
  4. Click Search for a Group.
  5. Enter the group name then press Search to find and select the group you want.
  6. Assign privileges to the group, just as you would for a user.  This essentially assigns those permissions to the domain users who are members of the group.  NOTE: DPA does not currently support single signon for Individual accounts.  It only supports Active Directory Groups at this time.
  7. Press Save

After completing the above steps, all domain users in the selected group will immediately be able to login to DPA using their domain username and password and will have the privileges that you set up for the group in DPA.

You can add multiple AD/LDAP groups in DPA.  If a domain user is a member of more than one group, DPA will grant them the combined privileges from all of their groups.

Log in using Active Directory

When AD is configured in DPA, the username and password entered in the DPA login screen are first used to attempt to login as an DPA “custom” user.  If not found, DPA will then attempt to authenticate to AD by first searching for a matching username and then authenticating using the supplied password.  

DPA supports 3 types of logon name formats for Active Directory:

  1. SAM Account Name (e.g. username)
  2. User Principal Name (e.g. username@domain.local)
  3. NT/AD (e.g. domain\username)

The following explains how DPA searches for the user given each format:

  • SAM Account Name (e.g. jsmith)
    • This basic format does not match on domain information and may result in the search returning duplicate user names. If this happens, DPA will report that multiple users were found and not permit the login.
  • User Principal Name (UPN) (e.g. jsmith@domain.local)
    • This is the most specific format, since AD does not permit duplicate entries.
    • Your administrator might specify the UPN using a domain alias (e.g.  DPA supports the use of aliases.
    • The search for the UPN might not work if the UPN is not “explicitly” set in AD.  In this case, DPA will lookup the username (e.g. jsmith) against the SAM Account Name.  If found, DPA verifies that it has found the correct user by matching the domain of the user returned by the search to the domain entered in the original UPN login (e.g. domain.local).
  • NT/AD (e.g. domain\jsmith or child.domain\jsmith)
    • This is a commonly-used, but outdated format that is not directly supported by AD’s LDAP interface.
    • DPA first converts the login name to UPN format (e.g. jsmith@domain), and then does a wildcard search against the User Principal Name (e.g. jsmith@domain*).  If a single matching user cannot be found, then DPA converts the entered login name to the SAM Account Name format (e.g. jsmith) and searches for the user that way.  If a single user is found, DPA verifies that the domain entered (e.g.domain) in the original login name matches the domain returned from the user search (e.g. domain.local).



Authentication information and errors are logged in the following file:


 Useful command line utilities for Active Directory

If you need to figure out a user’s name, fully qualified domain name (FQDN), or user principal name, login to Windows as that user and run the following from the command line:


 Get information about which Active Directory groups a user belongs to:

net user /DOMAIN loginName

 Get a list of all users that belong to a particular group:

net group /domain "Domain Users"
Last modified