DX Application Performance Management

Document ID:  TEC595290
Last Modified Date:  7/12/2013

Author: Mary_Clark

• Products
  • CA Application Performance Management
• Components
  • INTROSCOPE

Description:CA APM gives you choices for securing and authorizing access to some or all of the features and domains of the Enterprise Manager and Workstation. Using LDAP, you can authenticate user and group access with CA APM while maintaining user and group authorization in local configuration files.There are 3 ways to secure CA APMLocal - Users and groups are both authenticated and given authorization via local configuration files maintained on the Enterprise Manager server.LDAP - Users and groups are authenticated by LDAP directories but authorized by local configuration files maintained on the Enterprise Manager server or CA EEM.EEM - Users and groups are both authenticated and authorized by a CA EEM (CA Embedded Entitlements Manager) server for CA APM activities.This article discusses how you can integrate CA APM with your own LDAP directory for authentication to the APM Workstation and Enterprise Manager.Solution:How to configure CA APM for LDAP AuthenticationFollowing are instructions for implementing LDAP for Introscope. To implement LDAP for CEM, the only difference is that you must create the 4 CEM groups in your LDAP directory manually and add users as members.The default CA CEM security user groups are:

• Admin-has both Introscope and CA CEM access, and is given both Introscope Admin as well as CEM System Administrator privileges.
  
  
• CEM System Administrator-manages all CA CEM system functions
  
  
• CEM Configuration Administrator-manages general CA CEM configuration
  
  
• CEM Analyst-has access to CA CEM reports and views only
  
  
• CEM Incident Analyst-has access to CA CEM reports and views, including HTTP information on defects.

Users.xml is not used for LDAP authentication.

An LDAP browser is handy for testing connectivity to the LDAP directory and interrogating its structure.

Apache Directory Studio is a free LDAP browser you can download from the internet.

On the Enterprise Manager, you will need to define the user who will make the LDAP bind. The bind user must have permission to query the LDAP directory.

Test connectivity to the LDAP server using Apache Directory Studio.

In ADS, create a new connection.
Click LDAP, select New Connection

Connection Name - A unique name you provide to identify this connection to your LDAP directory
Hostname - The LDAP Server host name
Port - 389 (the default unsecured, non-SSL LDAP port)

The Base DN is the node that is displayed at the top of the LDAP Tree. This is the root node.

Copy the User DN to the Bind DN parameter for creating a new connection. If you are unsure what the DN should be, get this information from your LDAP administrator.

Replace CN=Administrator with CN=YourUserName to test the ability of the LDAP server to authenticate YourUserName using YourUserName's password as stored in LDAP.

Click Check Authentication

Now try to connect to the LDAP Directory using these credentials.

Connection was successful. The LDAP directory can be browsed.

If there are problems with LDAP authentication, test the connection using a 3rd party utility like Apache Directory Studio or LDAP Browser.

How to configure Introscope Enterprise Manager to use LDAP for authentication of users.

Go to C:\[EM_HOME]\config
Edit realms.xml

Realms.xml tells the Enterprise Manager what type of authentication to use. By default, APM will use Local Users and Groups authentication and not LDAP, meaning that APM will try to authenticate with user ids and passwords stored in C:\[EM_HOME]\config\users.xml.

To implement LDAP authentication, you must update 3 files:
Realms.xml - to specify that LDAP is to be used
Server.xml - to grant permissions to the LDAP user
Domains.xml - to specify domains for agents and Management Modules to which permissions are granted

You can configure mixed-mode authentication so that some users are authenticated via LDAP and some are authenticated locally. By allowing an APM administrator to be locally authenticated, you ensure that you will always be able to login to APM - even if your LDAP server is down.

For mixed mode, define an "LDAP realm" and a "Local Users and Groups" realm in realms.xml.
Introscope will try to authenticate via the realm listed first in realms.xml. If it cannot, it will try to authenticate using the next one.

Here is an example realms.xml. Introscope will attempt the first authentication realm in the file. If that fails, it will fall through to the next authentication realm in realms.xml.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <realms xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="0.1" xsi:noNamespaceSchemaLocation="realms0.1.xsd"> <realm descriptor="Local Users and Groups Realm" id="Local Users and Groups" active="true"> <property name="usersFile"> <value>users.xml</value> </property> </realm> <realm descriptor="LDAP Realm" id="LDAP" active="true"> <property name="userObjectQuery"> <value>(&amp;(objectClass=organizationalPerson)(cn={0}))</value> </property> <property name="scopeDepth"> <value>subtree</value> </property> <property name="baseDN"> <value>DC=ca,DC=com</value> </property> <property name="bindPassword"> <value>ux639acDEL3lBzM3iIpuRv64Lb/SLHdF</value> </property> <property name="groupNameAttribute"> <value>cn</value> </property> <property name="url"> <value>ldap://myldap.ca.com:389</value> </property> <property name="disallowEmptyPassword"> <value>true</value> </property> <property name="bindAuthentication"> <value>simple</value> </property> <property name="bindName"> <value>cn=SVC-Wily,ou=special accounts,ou=admin,dc=ca,dc=com</value> </property> <property name="groupObjectQuery"> <value>(&amp;(objectClass=group)(cn={0}))</value> </property> <property name="useSSL"> <value>false</value> </property> <property name="plainTextPasswords"> <value>false</value> </property> <property name="groupMemberQuery"> <value>(&amp;(objectClass=group)(member=%u))</value> </property> <property name="usernameAttribute"> <value>cn</value> </property> </realm> </realms> 

LDAP Properties

bindName - the userid used to connect (bind) to the LDAP directory on the LDAP server. This is the same userid you tested in Apache Directory Studio to make a new connection with.

You can get the value needed for bindName from Apache Directory Studio by selecting the user (wilyuser here) and copying the string from the heading in the details window:

CN=wilyuser,CN=Users,DC=xxxxxxac0,DC=ca,DC=com

baseDN - specifies where to find the user in LDAP. It is the part of the string following the username:

bindPassword - will be the password for the bindName user. Enter it in clear text.

url - specifies the location and port of the LDAP server.
389 is the default, clear text port for all LDAP servers.

disallowEmptyPassword - is a property that means what it says. When true, all users require a password.

bindAuthentication - this property specifies whether to use simple authentication or not.

useSSL - specifies whether communications to/from the LDAP server should be over SSL or not.

plainTextPasswords - specifies whether passwords (the bindPassword, above) are entered by you in plain text or encrypted.

This property is used in conjunction with the bindPassword property. If you enter a plain text password in the bindPassword property, this value must be true. At the next restart of the Enterprise Manager, it will automatically encrypt the password you entered and set the value of plainTextPasswords to false. This is how you encrypt passwords stored in configuration files in APM.

usernameAttribute - this property specifies which attribute holds the username. In our case, it is "cn" as can be seen in the bindName property in the ADS browser. This is the attribute used in a user search of the LDAP directory.

userObjectQuery - specifies the search query to locate a user in the LDAP directory. This string is always the same, but the objectClass will likely be different at every company. To find the correct value for userObjectQuery, consult with your LDAP administrator.

You will need to know what attribute is used to store the username. In our case it is "cn", but almost any attribute name is allowed. The query must agree with the userNameAttribute property.

Some examples are cn, givenName, sAMAccountName, or some other attribute to store userids. The query must return the right userid.

The search query will look for the attribute "cn" in the objectClass "organizationalPerson".

For this to work, the LDAP directory must be structured such that it has an objectClass with this name that contains an attribute "cn" that contains the userid of the user attempting to login to the Enterprise Manager.

scopeDepth - "subtree" says to search from the top down through LDAP child nodes as necessary to locate the cn equal to the userid typed at the login prompt. Specifying "subtree" allows EM to search across subnodes in LDAP to find the user.

Specifying subtree allows you to search through nested groups in LDAP to locate the user's entry.

If the LDAP structure is large and complex, searching through subtrees can take a lot of time and delay logins. To test this, you can move one user to the root of the LDAP tree to see if login performance improves. As an alternative, you can move the baseDN to the subnode where APM users reside, so that the search starts from that point rather than from the top of the tree.

To test LDAP authentication with the binding user "wilyuser", add wilyuser to domains.xml and server.xml so that the user has permission to do things in the Enterprise Manager once logged in.

SSL can negatively affect performance.

Once you can login as the bind user, test with a different user.

Be sure the user has been granted permissions in server.xml and domains.xml. No changes are needed to realms.xml. The only user you need to define in realms.xml is the bind user who connects to LDAP to do the query.

LDAP authenticated users do not have to be listed in users.xml.

Grant an LDAP group permission to connect to the Enterprise Manager .

Grant the group permissions in server.xml and domains.xml.

You need to know the LDAP attribute that contains the group name. In our case, it is "cn" just like the user name.

Add the property groupNameAttribute to realms.xml

Add the property groupObjectQuery to realms.xml

Add the property groupMemberQuery to realms.xml

When you login, APM will try to find the name of the user. For that user, it will check the memberOf attribute. If the user is a member of wilygroup, it will run the groupObjectQuery to locate the wilygroup object, then run the groupMemberQuery to check that the user is a member of the group.

It is OK to mix group permissions in server.xml and user permissions in domains.xml.

Search the Entire CA APM Knowledge Base