This page provides instructions on how to integrate an AppDynamics Tenant with LDAP directory servers. 

This page assumes a Controller and a Tenant are one and the same. 

LDAP Support

You can delegate Tenant UI authentication and authorization to external directory servers that comply with LDAP (Lightweight Directory Access Protocol) version 3.

While a Tenant should be able to work with any LDAPv3-compliant server, these LDAP products have been verified:

  • Microsoft Active Directory for Windows Server 2008 SP2 or later
  • OpenLDAP 2.4 or later

To configure LDAP authentication on a Tenant, you must configure connection settings to the LDAP server and the queries that return user or group data. By mapping LDAP groups to roles, you can provision permissions in the AppDynamics Tenant based on LDAP groups.

  • What happens if the LDAP server becomes unavailable?
    If the LDAP server configured for Tenant authentication becomes unavailable for any reason, the Tenant falls back to local user authentication. Given this possibility, you should provision local user accounts in AppDynamics for the administrative users who will need access if the LDAP server becomes unavailable.

  • What happens if a user cannot be found in the LDAP directory?
    If a user cannot be found in the LDAP directory, the authentication failure event is logged as a warning. The user, whether a regular Tenant user or a REST client user, may still be authenticated through local authentication.

Prepare the LDAP Directory for AppDynamics Integration

To use an LDAP authentication provider, your AppDynamics Tenant must be able to connect to the external LDAP server. We recommend creating a user account in LDAP specifically for the Tenant to use to authenticate itself to the server and run the queries. The Tenant user only needs to have search privileges in LDAP.

You can map existing LDAP group definitions to roles in AppDynamics, however, your existing groups may not correspond directly to those roles. You can map LDAP groups to Tenant roles by creating a group in LDAP for each role you want to map in AppDynamics. LDAP groups for each role provide you with a manageable, one-to-one correspondence between your LDAP groups and AppDynamics roles.

This is a possible LDAP group scheme for mapping in AppDynamics:

  • AppDynamics-AppA-ReadOnly
  • AppDynamics-AppA-Admins
  • AppDynamics-AppA-DashboardViewers
  • AppDynamics-AppB-ReadOnly
  • AppDynamics-AppB-Admins
  • AppDynamics-AppB-DashboardViewers

The sample group names imply having custom roles in AppDynamics targeted to specific applications, AppA and AppB.

Naming the groups with a common prefix, as the AppDynamics- prefix in our sample, allows you to use an LDAP group filter. A group filter for the sample groups could be:

(&(objectClass=group)(cn=AppDynamics-*))
CODE

Use Paged Results for Large Result Sets

LDAP servers are sometimes configured to limit the number of entries they can return in a query response. If the results of your user or group query exceed that limit, AppDynamics reports a max_results_exceeded error.

To avoid this error, refine your query filter to produce a smaller result set. The results must include the users who will need to access the AppDynamics UI. 

If your LDAP server supports it, you can enable paged results in the Tenant LDAP configuration. With paged results, the LDAP server divides the result set into separately transmitted blocks.

The paged results feature applies to the behind-the-scenes interaction between the AppDynamics Tenant and the backend LDAP server. It does not affect the UI view of the data.

LDAP Authentication with a SaaS AppDynamics Controller

Depending on your organization's security policies, it may not be possible to use LDAP authentication with the SaaS AppDynamics Tenant. Doing so requires opening your firewall to permit Tenant access to your corporate LDAP server.

To enable LDAP authentication with an AppDynamics SaaS Tenant, however, you must permit access through the firewall for the AppDynamics IP ranges listed in Cisco AppDynamics SaaS Domains and IP Ranges. The firewall rule should allow incoming LDAP requests from the Tenant at the LDAP port you configure.

Before You Start

To perform LDAP configuration, you must have:

  • An LDAP server. There is a one-to-one correspondence between an AppDynamics account and an LDAP server.
  • An account on an AppDynamics SaaS or on-premises Tenant
  • Account administrator privileges on the AppDynamics Tenant, as described in Update the Root User and Glassfish Admin Passwords.
  • Network connectivity between your LDAP server and the Controller. If using a SaaS Tenant, the LDAP server may not be accessible to the Tenant without enabling access through your network firewall. See LDAP Authentication with a SaaS AppDynamics Controller.

Configure LDAP Authentication

The high-level procedure to set up LDAP authentication includes:

  • Configure the connection to the LDAP server.
  • Configure and test the LDAP query that returns users to be provisioned in the AppDynamics Tenant.
  • Configure the LDAP query that returns the LDAP groups to be mapped to AppDynamics roles.
  • Map the users or groups to roles in AppDynamics.

Configure the Connection to the LDAP Server

As an Administrator or Account Owner in the Tenant UI, you can configure LDAP authentication by navigating to Settings > Administration and selecting LDAP in Authentication Provider

Use the following paged results configuration if the user or group query you need to use returns more entries than the LDAP server permits:

  • Enable Paging: Check this option to have the Controller request paged results from the server when submitting user or group queries.
  • Page Size: Enter the number of entries per round-trip from the AppDynamics Controller to the LDAP server. The default is 500. 

The page size should equal the total number of entries to be returned divided by the tolerable number of round trips between the LDAP server and the Tenant. For example, if you expect to receive 1200 results in a query and you can tolerate a maximum of two round trips, set the page size to 600 (1200/2). See Using Paged Results for Large Result Sets.

Configure the LDAP connection settings: 

  • Host: Required address of the LDAP server.
  • Port: Port on which the LDAP server listens. The default is 636 for an SSL connection and 389 if not using SSL. Required.
  • Use SSL: Enabled by default to use a secure connection to the LDAP server. Clear if not using SSL.
  • Enable Referrals: Enabled by default to support LDAP referrals. A referral is when an LDAP server forwards an LDAP client request to another LDAP server. Each referral event is referred to as a hop.
  • Maximum Referral Hops: The maximum number of referrals that AppDynamics follows in a sequence of referrals. The default is five.
  • Bind DN: Distinguished Name of the user on the LDAP Server on whose behalf the AppDynamics application searches. Required.
  • Password: Password of the user on the LDAP server. Required.   

Configure Users

In the LDAP Configuration page, configure information to find LDAP users:

  • Base DN: Location in the LDAP tree to begin recursively searching for users. Required.
  • Filter: Optional LDAP search string that filters the items matched from the base DN. See RFC2254 for information about LDAP search filters.
  • Login Attribute: The LDAP field that corresponds to the username users will enter when logging in to the AppDynamics UI. The default is uid. For Active Directory, this would typically be sAMAccountName.
  • Display Name Attribute: The LDAP field to use as the user's display name.
  • Group Membership Attribute: Optional user group membership field. Recommended for faster retrieval.
  • Email Attribute: Optional user email address. 

Select Test Query to check the connection. If successful, a screen displays the first few users returned by the query. The test does not return the entire result set if the result set is large.

Configure Groups

Optionally, you can map LDAP groups to user roles in the AppDynamics Tenant. To do this, you must set up the LDAP query that returns the LDAP groups to map:

  • Base DN: Location in the LDAP tree to begin recursively searching for groups. Required.
  • Enable Nested Groups: Option to include nested LDAP groups to a depth of 10.
  • Filter: Optional LDAP search string that filters the items matched from the base DN. See RFC2254 for information about LDAP search filters.
  • Name Attribute: The LDAP field that contains the name of the group. Default is cn. Required.
  • Description Attribute: The LDAP field that contains a description of the group. Optional.
  • User Membership Attribute: Identifies members of the groups. Optional.
  • Referenced User Attribute: Optional child attribute of the User Membership Attribute. Disabled if the parent is empty. Identifies the property of the user that the user membership attribute contains. 

Select Test Query to check the connection. If successful, the first few groups returned by the query are shown.

You can now assign permissions in the AppDynamics Tenant to users or groups.

Assign AppDynamics Permissions to an LDAP User

  1. In Settings > Administration, click Users. If LDAP is enabled and correctly configured, the AppDynamics Tenant fetches the user names from the LDAP server.
  2. Select the name of the user to whom you want to assign permissions.
  3. Add or delete the Roles that you want to assign to this user. You can assign multiple roles to a user. 
  4. Click Save.

Assign AppDynamics Permissions to an LDAP Group

LDAP Group configuration is optional.

  1. In Settings > Administration, click Groups. If LDAP is enabled and correctly configured, AppDynamics fetches the group names in LDAP.
  2. Select the name of the group to which you want to assign permissions.
  3. Add or delete the Roles that you want to assign to this group. You can assign multiple roles to a group.
  4. Click Save

Configure the LDAP Cache Synchronization Frequency

The Tenant keeps information about LDAP users and groups in a local cache. It regularly connects to the LDAP server to synchronize its cache with the LDAP server.

The Tenant caches information about users and group membership. It does not cache user passwords. Accordingly, the Tenant authenticates the user credentials against the LDAP server at the start of every user session.

If you remove a user account from LDAP, the change reflects immediately and the user will not be able to log in to the Tenant UI. However, if the user has an existing session in the Tenant UI, that session continues until the user logs out or the session expires. 

If the user's access to the Tenant is based on group membership and you remove the user from the group but maintain an account in the LDAP server, the user is able to log in to the Tenant until the next LDAP server synchronization. The default synchronization frequency setting would allow the ability to access the Tenant UI for up to an hour. 

Configure the LDAP Synchronization Frequency

To modify the default synchronization frequency of one hour:

  1. Stop the Tenant application server by running the following command from the Enterprise Console host command line:
    • From Linux, run:

      platform-admin.sh stop-controller-appserver
    • From Windows, run this command from an elevated command prompt (which you can open by right-clicking the Command Prompt in the Windows Start menu, and select Run as administrator):

      platform-admin.exe cli stop-controller-appserver
  2. Open the <Controller-Installation-Directory>/appserver/glassfish/domains/domain1/config/domain.xml file for editing.
  3. In the <jvm-options> element, add a system property named appdynamics.ldap.sync.frequency with the desired synchronization frequency in milliseconds.
    For example, to have the Tenant synchronize to the LDAP server every 15 minutes (900000 milliseconds), add: 

    <jvm-options>-Dappdynamics.ldap.sync.frequency=900000</jvm-options>

    The default is 3600000 milliseconds (1 hour).

  4. Save the file.
  5. Restart the Tenant app server:
    • From Linux, run: 

      platform-admin.sh start-controller-appserver
    • From Windows, run this command from an elevated command prompt:

      platform-admin.exe cli start-controller-appserver