1. Home
2. Developer Connection
3. Contribute Developer Center

Contribute Article

Integrating Contribute Publishing Services with LDAP

Sarge Sargent

Macromedia

Macromedia Contribute Publishing Services (CPS) is the server component in the Macromedia Web Publishing System (WPS). CPS provides a method of centrally managing publishing access to websites and tracking publishing activities. Administrators are drawn to CPS for its integration with Lightweight Directory Access Protocol (LDAP) servers─including Microsoft Active Directory. CPS also offers file-based user directory administration, however, leveraging the LDAP integration allows CPS to scale with your enterprise.

Although the LDAP integration is one of the main draws of CPS, customers often encounter sometimes challenging experiences setting up the integration. I found there were three reasons for this with the initial release of CPS:

1. Lack of LDAP experience/knowledge of the CPS admin
2. Lack of multi-branch and subtree search support in CPS
3. Dissatisfaction with LDAP documentation for CPS

The CPS 1.1 update takes care of the third issue by enabling LDAP multiple branch support and subtree searches. Now that may be foreign to some readers but this article will offer clarity and also eliminate problems one and two. To successfully configure CPS for LDAP you will need to know the following from the LDAP administrator:

• The distinguish name (dn) for each node or branch containing users and groups (for example, ou=Employees,dc=macromedia,dc=com)
• The correct objectClass attribute for user and group objects, respectively (for example, objectClass=person)
• The correct bind DN format for user accounts (if using LDAP bind for authentication) (for example, uid=sarge,ou=Employees,dc=macromedia,dc=com)

Let’s get started with a brief LDAP primer.

Requirements

To complete this tutorial you will need to install the following software and files:

Macromedia Web Publishing System

(Specifically, Macromedia Contribute Publishing Services 1.1)

• Try
• Buy

Pricing Options for Macromedia Web Publishing System

• Learn more

LDAP Server or Active Directory (including Microsoft Exchange Server)

• The server should already be populated
• You should implement Lightweight Directory Access Protocol version 3

Prerequisite knowledge:

• Basic knowledge of where users and groups are stored in the directory
• A directory Admin account username and password
• General understanding of LDAP version 3 is a plus

LDAP Primer

When I talk with most CPS customers, they are not the actual LDAP administrator, and really have no interest in learning LDAP at all. They just need to implement CPS to complete their WPS rollout. However, before you begin configuring CPS for LDAP integration, here are some pointers and terms about LDAP you should know:

• LDAP stands for Lightweight Directory Access Protocol.
  • LDAP is a protocol for accessing Directory Services (for example, Microsoft Active Directory/Exchange, IPlanet Directory Server, Novell Directory Services, and so forth).
  • CPS supports LDAP version 3 compliant LDAP servers (RFC 2251).
• LDAP servers contain objects─everything is represented as an object.
• LDAP objects are stored in a hierarchical structure called the DIT (Directory Information Tree) and organized into nodes or branches (also called leaves)–see Figure 1 below.
• Each object has properties (called attributes) and instantiates one or more object class (specified in the objectClass attribute).
  • An objectClass is both an attribute and an object.
  • An objectClass can be subclassed and most extend the top object class (objectClass=top).
• Object properties are stored in name/value pairs.
• Each object contains a distinguished name (dn) attribute which uniquely identifies the object in the DIT.
• Typical LDAP attributes are:
  • dn (Distinquished Name)–uniquely identifies an object in the DIT
  • cn (Common Name)–a common or full name for an object in the DIT
  • uid (User ID)–a user id for a user object
  • sAMAccountName–Windows domain logon name (Active Directory/Exchange Server only)
  • mail (Email)–an object’s e-mail attribute
  • objectClass (Object Class)–a grouping of attributes
  • ou (organizationalUnit)–typically a department within an organization
  • o (organization)–typically an organization within a company
  • dc (domain component)–A portion of the domain name (or DNS name)

Note: LDAP attribute names are usually case-insensitive, but it is best practice to use the correct case (or mix-case) in spelling them.

Your company’s user directory is an LDAP server (or a server implementing a version 3 LDAP interface) and contains user and group objects─each with their own respective DN attributes. The user objects are organized into groups for better management. Contribute users authenticate to the user directory with their username (or DN) and password. Administrators assign rights and permissions to groups, and it is the user’s group membership that provides authorized access.

Now that you have an idea of the LDAP components you will be dealing with, I will review setting up the CPS LDAP settings.

Figure 1. An example directory information tree

User Directory Settings

The default user directory for CPS is file based. File-based user directories are good for testing purposes or with a finite group of users. To begin the LDAP integration, you must manually change to LDAP/Active Directory. Log onto the CPS Administrator (typically https://localhost:8900/contribute/admin/server.cfm) and access the User Directory screen (click the User Directory link under Service Settings in the left navigation section). Change the directory type to LDAP/Active Directory and click OK on the changing directory type warning message. The display changes to a four-tab interface: Settings, User Search, Group Search, and Test.

Use the Settings tab to configure connection and bind information for your LDAP server. The URL field provides the LDAP connection. The proper syntax for this field is:

ldap://<servername or IP address>:<port number>

For example, to connect to my LDAP server I would enter ldap://ldap.macromedia.com:389. This provides a non-secure LDAP connection. To configure a secure LDAP connection, see Configuring Contribute Publishing Services to use LDAPS (TechNote 54f01608).

LDAP servers require an authenticated connection before they will allow queries (searches). This authenticated connection is called a bind. Most LDAPs allow an anonymous bind─where no username or password is submitted; however, others restrict searches to its members and require an authenticated username and password. If your LDAP requires authenticated access for read-only searches, enter a bind DN and bind password in the Access username and password fields (respectively) on the Settings tab. The syntax for the bind DN depends on the LDAP server itself—some will take <domain name>\<username> (macromedia\ssargent), or cn=username (cn=ssargent), or a simple username (ssargent). Your LDAP administrator should provide this information.

The syntax for the bind DN is also important for the Authentication method. The authentication method determines how users enter their username when Contribute challenges them for authentication. If you choose LDAP bind (default), then you must configure the Prefix and Suffix fields. The bind syntax for this method is: prefix + <username> + suffix. Using my DN (uid=sarge,ou=Employees,dc=macromedia,dc=com) as an example, the prefix is the part of the bind DN before the username value (uid=), and the suffix is the remainder of the DN (,ou=Employees,dc=macromedia,dc=com). It is important to include the comma (,) in the suffix or the authentication will fail.

You should only use the default LDAP bind if you have a simple DIT—meaning all of your users are stored in one node. Choose LDAP bind (auto-find user DN) if you have users in multiple branches. This method uses the provided username and performs a query to retrieve the authenticating user’s DN; it then uses the retrieved DN (and provided password) to perform the bind. This provides greater flexibility but may increase response time.

The Password in directory authentication method simply requires a username for the bind DN. CPS uses filtering to perform the authentication. Typically used with Active Directory, the Windows domain authentication type uses the user’s Windows domain login ID for the bind in the format: <domain name>/<username>. The user must provide their correct Windows domain login ID and password for a successful bind.

Figure 2. Choosing the authentication method on the CPS 1.1 Settings tab

The final fields on the Settings tab, which I skipped, are the Max search results and Connection timeout. The Max search results is the number of results to display for the test search on the Test tab. The Connection timeout is the maximum number of seconds to wait for a search result. The default value is zero (0)—or no timeout.

Now that the connection is configured, I will turn to setting up the filters for our searches.

User and Group Filters

Use the User and Group Search tabs to enter filter parameters used to find and authenticate users. Each tab contains fields for you to enter common user attributes, and a list for you to enter one or more branches of your LDAP or Active Directory to search. CPS 1.0 had the same attribute fields but only allowed for the entry of one branch.

On the User Search Tab, enter the following attributes:

• Full Name attribute: Enter cn or the attribute which represents a user’s full name in your LDAP or Active Directory.
• E-mail attribute: Enter mail or the attribute which represents a user’s e-mail address in your LDAP or Active Directory.
• Username attribute: Enter uid or the username attribute which represents a user’s id in your LDAP. For Active Directory enter sAMAccountName.

Note: CPS 1.1 tabs contain a Choose… button for each field, which displays a list of common values for the field. This list is not comprehensive and may contain entries that are not valid for your LDAP or Active Directory.

Click the Add… button to enter the branches that contain the user entries in your LDAP or Active Directory. On the Add User Branch dialog box, enter the full DN of the branch containing user entries. The branch is typically an organizational unit (ou) or a group. For example, my DN is:

cn=sarge,ou=Employees,dc=macromedia,dc=com, 

This means the my user account (and any adjacent user accounts) are stored in the ou=Employees,dc=macromedia,dc=com branch.

Enable subtree searches by checking the box next to Scope. Subtree searches begin searching at the specified branch and extend to the branches beneath it. This can be useful when trying to discover where user objects are stored. However, since this also slows performance, specify the closest branch to your user objects as possible.

Figure 3. Adding the branch DN

Next, enter a search filter in the Filter field. The search filter is an object class instantiated by the user’s object. The schema for each object includes one or more objectClass attribute. Enter the objectClass attributes name/value pair in this field. Typically you will enter (objectClass=person) or (objectClass=user)─do not forget to include the parenthesis. For completeness I recommend entering:

(&(objectClass=top)(objectClass=person)) 

Again, these values may differ in your LDAP or Active Directory configuration.

Figure 4. User Search tab options

The Group Search tab contains the same fields as the User Search tab. For the user attribute fields, enter the same respective values from the User Search tab. In the Membership attribute field, specify the name of the group object’s attribute that holds the names or DNs of its members. This is usually governed by the group’s object class but typically you will enter member or uniqueMember. If your group’s object class equals group (or container), then enter member; if the object class equals groupOfUniqueNames then enter uniqueMember.

The branches on the Group Search tab work the same as those on the User Search tab. However, on this tab you want to enter the DN of branches containing your groups. The branch DN should be a different area of the DIT than the user objects. Using my example DIT, you can see my groups are Breeze, ColdFusion, Flex, and JRun, and these are in the

ou=Server Product Support,o=World Wide Customer Care, dc=macromedia, dc=com

branch. Each group object has a uniqueMember attribute that specifies my user object’s DN. I enter:

ou=Server Product Support,o=World Wide Customer Care, dc=macromedia, dc=com

as my branch DN and enable a subtree search. Specify the object class of your groups for the filter. A group typically instantiates one of three object classes: group, groupOfNames, or groupOfUniqueNames. The groups in my DIT instantiate the groupOfUniqueNames object class. So I will use:

(&(objectClass=top)(objectClass=groupOfUniqueNames))

Be sure you enter the correct values for your LDAP or Active Directory configuration.

Figure 5. Group Search tab options

The entries on these User and Group Search tabs are vital to successful CPS integration. If you misconfigure any of these fields or omit any of the values, your user and group search test will fail. Next you will test your entries.

Testing the Connection

The Test tab is broken into two sections: User and group search test and Authentication test. Enter a user or group criteria in the Search for field and click the Test Search button. Results are displayed in the table–showing the full name, e-mail address, and type (user or group) for each result. You can enter values for the attributes specified on the User and Group Search tabs–full name (or a partial name), group name, e-mail address, username/user id, or any letters that constitute any of these. For example, I can enter my e-mail address (ssargent@macromedia.com) or the letters ssar to retrieve my user entry. You can also perform a "*" or "all" search by just clicking Test Search without specifying any criteria. The test in this area uses the filters specified in the User and Group Search tab. CPS will use these same filters for authorization requests coming from Contribute.

The Authentication test area uses the connectivity information on the Settings tab. Enter the username and password of a user to authenticate. For the most part you can enter a simple username (e.g. sarge) and the test should complete successfully. The syntax actually depends on the authentication method specified on the Settings tab. If you chose LDAP bind, then you will need to enter the name that is part of the user’s DN–for my entry this is sarge. CPS will surround the input with the supplied prefix and suffix. You should also enter the user’s user id for LDAP bind (auto-find user dn) and Password in Domain. If you chose Windows domain, then you must enter the user’s Windows domain login─you may need to enter domain name as well (for example, macromedia\sarge).

Change the relative settings for that area should you get errors with either test. Try modifying the filters and branch DNs should user/group searching fail. Make sure you spell and punctuate everything correctly. Should your authentication fail, try changing the authentication method. You may need to change the prefix and suffix values. You may even need to add a new branch DN to the User Search tab. One technique is to use the LDAP Bind (auto-find user dn) authentication method and modify the branch DNs. Now that you have the fundamentals you should be comfortable with making changes to any of the tabs.

Where to Go from Here

This article has shown you how to successfully integrate Contribute Publishing Services with an LDAP or Active Directory user directory. The key points to remember are:

• The distinguished names for your branch nodes containing your users and groups
• Choosing the correct filters and attributes for the Users and Group Search tabs
• Choosing the correct authentication method and supplying the appropriate prefix and suffix for a successful LDAP bind.

If you have these points configured properly, your test queries should return with valid user and group entries and you should be able to successfully test authentication.

However, should your tests fail and you need to contact Macromedia Product Support, please have the following information available for the product support engineer:

• Your cps_web_root\WEB-INF\config\ckm.xml file
• Your LDAP server's IP address and DNS name
• An admin user account for proper bind account
• The full DN for each Branch node containing your users and groups
• Your user object's full DN
• Some schema data regarding the user object and the group(branch nodes) objects, such as the required objectClass attributes for each

In my next article, I’ll discuss debugging the CPS connections using internal and external tools. Stay tuned.

About the author