IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Administrator's Guide > Enable user authentication > LDAP user authentication using Microsoft Active Directory > Enable and configure LDAP user authentication for the portal server, if desired

IBM Tivoli Monitoring, Version 6.3 Fix Pack 2

---

Start the TEPS/e administration console

If you are having issues accessing http://localhost:15205/ibm/console, ensure you have completed the TEPS/e enablement and password-setting steps detailed in Start the TEPS/e administration console. Also, if you wish to use the TEPS/e interface, you must enable it each time you restart the portal server. (Note that enabling TEPS/e controls only the TEPS/e interface; it does not control the portal server's LDAP enablement.) Log information for this activity can be found here:

• %CANDLE_HOME%\CNPSJ\profiles\ITMProfile\logs\ITMServer

• $CANDLEHOME/$INTERP/iw/profiles/ITMProfile/logs/ITMServer

When performing the steps described in Configure the portal server for LDAP authentication using the TEPS/e administration console, observe the notes below.

• A realm identifies a set of federated repositories in TEPS/e and other WebSphere Application Servers. You can choose your own realm name but this value must be the same across all applications that are configured for SSO within an Internet or intranet domain. If you are not configuring SSO, you should accept the default for the Realm name, unless this name is already in use in your environment.

  Figure 1. Accept these default values

• When entering your Repository identifier choose a descriptive name.

  The Repository identifier will become a reference label for a configuration container within TEPS/e that will hold your LDAP server information, your LDAP Bind password, and your LDAP Login properties; this is the Active Directory User Class attribute to search for an exactly matching portal server userid (see Figure 3).

  Additionally, this Repository will be associated with one or more LDAP Base values (containers) that the portal server's LDAP authentication will search. Again, as pointed out in Before you begin, OU planning is recommended for this configuration step. Good OU planning restricts IBM Tivoli Monitoring LDAP user authentication searches to the Base and below. Grouping users within the ITMtepsUsers OU (see Figure 1) is recommended for efficient Base searches and LDAP user authentication performance.

  Figure 2. Configure the repository

  General Property → Repository identifier

  This is a freeform field. It is recommended that you choose a meaningful name here that administrators can associate to the users defined within your Active Directory environment. In this case ITMtepsUsers is specified, as this will be the only Repository created for portal server LDAP user authentication within our environment. It would also be appropriate to name your repository using a convention that reflects the LDAP Bind password account configured within. An example for this case may be to use a derivative of a Forest Name or a Domain Name if you will require different repositories to allow you to configure different LDAP Bind passwords to meet your requirements.

  LDAP Server Property → Directory type

  The value provided here must match your Forest level. Our sample Forest is running at an Active Directory 2003 level.

  LDAP Server Property → Primary host name

  A Domain Controller within the Active Directory Forest that is hosting the User accounts you created earlier for portal server LDAP user authentication. Your choice here should be driven by the hierarchy level within your Forest that owns the IBM Tivoli Monitoring users' OU. Consider your selection here in light of possible issues with IBM Tivoli Monitoring LDAP authentication due to Active Directory connectivity or replication failures of your Active Directory User objects.

  LDAP Server Property → Port

  The Active Directory LDAP default port value is 389. Match this value to your LDAP environment's port assignment.

  LDAP Server Property → Failover server used when primary is not available

  Additional Active Directory LDAP (DC) servers can be added here to compensate for replication or connectivity issues. This value should be completed with failover DCs (preferably with GC roles).

  LDAP Server Property → Support referrals to other LDAP Servers

  This is your choice. Consider whether your environment is closed or open (that is, there are no DCs within your DMZ).

  Security → Bind distinguished name

  The user specified here requires sufficient authority (that is, an applied policy) for searching the Active Directory directory Base. This user is the account that will connect, bind, and query the specified Login Properties. This value can be omitted if anonymous users can search the registry.

  Our example uses CN=Administrator,CN=Users,DC=company,DC=com, but this is not absolutely required if the user specified exists within the CN=Users,DC=company,DC=com container for Active Directory. However, this is not recommended, as it is better to be specific and use a complete Distinguished Name.

  Security → Bind password

  The password for the Bind distinguished name account above.

  Security → Login properties

  This configuration property is critical for Active Directory in that this is the name of the attribute within the Active Directory Name object that is used to reflect exactly the portal server's user name (see Figure 3).

  Security → Certificate

  The default value EXACT_DN is set for searching Active Directory and matching on an exact DN. It is recommended you keep this default value.

  Security → Certificate filter

  Selecting CERTIFICATE_FILTER for the Certificate field above requires LDAP filter parameters. These parameters map attributes within the client certificate to entries within the LDAP directory.

  Security → Require SSL communications

  Select this if you desire TLS/SSL LDAP communications. Click the radio buttons for the following options that apply to your TLS/SSL implementation:

  • Centrally Managed

  • Use specific SSL alias

• When specifying a Distinguished name of the base entry that uniquely identifies this set of entries in the realm and Distinguished name of the base entry in this repository see Figure 3 for reference.

  Now that you have a Repository configured, you need to add the Base entry as a starting point when searching for your Active Directory-defined portal server users' OU. You can define multiple Base entries for your repository if you require. Multiple Base entries should be required only if you have defined multiple directory Base locations (multiple OU hierarchies) for your Active Directory's portal server users.

  The information provided in this panel for the property Distinguished name of a base entry that uniquely identifies this set of entries in the realm will be reflected back into the Tivoli Enterprise Portal User Distinguished Name choices, as shown in Figure 6. It is this field that is made available from within the TEPS/e portal server configuration to associate the portal server-defined userid to an LDAP connect, bind, query, or select (see the login properties from Step 5).

  This property is freeform; it is the TEPS/e configuration DN. It is recommended that you use the convention O=DNofChoice. Your choice of DN should be meaningful for its relationship to your Active Directory-defined TEPS Users Base container (shorter is better). The examples here have assigned O=ITMtepsUser for clarity when viewing the Tivoli Enterprise Portal users' Distinguished Names in the Administer Users interface (see Figure 6). The example used here is redundant, since the Repository Name and the Base DN are very similar, but it is clear this Repository and Base are configured for accessing and binding our Active Directory-defined users.

  For Distinguished name of the base entry in this repository, specify the distinguished name (DN) for the base entry in the LDAP registry. It is the starting point for user searches in the LDAP server.

  Figure 3. Adding the Base entry to your realm. Note that this entry is associated with the ITMtepsUsers section of the Repository.

• When saving your Step TEPS/e configuration work use Figure 4 as a reference. Click Save.

  Figure 4. Save your TEPS/e configuration updates

  Also, while configuring your Repository and Base settings, remember to click OK when asked to verify your configuration settings. Clicking OK or Apply connects, binds, and queries the Active Directory LDAP database using your updated configuration settings. If there is an issue, the configuration panel returns a red error message like the one shown in Figure 5.

  Figure 5. TEPS/e configuration error message

  You must correct these errors before saving your configuration.

Once the TEPS/e configuration is completed and saved, you must recycle the Tivoli Enterprise Portal Server to see the TEPS/e-configured users listed as Distinguished Names (see the example for llassite in Figure 6).

Figure 6. Tivoli Enterprise Portal Administer Users screen. Distinguished Names resolve to the Base names configured within TEPS/e for the Repository; compare the values presented here with those shown in Figure 2.

Parent topic:

Enable and configure LDAP user authentication for the portal server, if desired

Next topic: Map portal client userids to LDAP Distinguished Names

---

+

Search Tips   |   Advanced Search