July 2008 Archives

If you'll recall, a few posts ago I promised to start fleshing out the presentation I gave at Participate in this blog. It's a somewhat boring task, since I already came up with a presentation, but since I gave the presentation and posted it to my blog, there has been a lot more interest in it than I anticipated.

Apparently, everybody else is just as confused about what search is and how it works as I was. So how about we break out the flashlight and provide a point of reference for the folks who weren't at Participate, or who prefer reference material to a presentation (I know I am in that camp).

What is Search?

As illustrated by the diagram below, when I talk about search, I simply mean a repository of information. On one side, information about the stuff we want to search is added to the repository and on the other side users or programs query that repository with requests for that information:

However, this is a somewhat simplified version of Search, since it interfaces with our portal in more ways than just the search box in the header.

Here is a comprehensive listing of search uses (that I know of):

• Portal Search Box - When you search for things in the portal as a non-administrator.
• Administrative Search - When you search for things as an administrator (folders, objects, etc)
• Knowledge Directory - All of the folder/document browsing screens are built from the search index, not the database. You can change this in Portal Admin Options, but it's not recommended, for performance reasons.
• Content Crawlers - Every time a new document is submitted, metadata is updated, etc (basically every time a crawler is run)
• Publisher - Used only when publishing/saving content. Publisher search is actually just a database query)
• Collaboration File Upload - Used when uploading/indexing Collaboration documents.
• Collaboration Search - Collaboration search actually does use Search.
• IDK Search Factory - When you use the IDK to perform search requests.

That's really it. In its basic operation, search is extremely simple. Next time I'll start to delve into search architecture, specifically Nodes and Partitions.

Since Fabien finally updated his blog with a nice write up on the published content redirect, and I told him I would try and beat him to the punch, I think I now owe a post or two. This one has been sitting unpublished for a few days, so here we go...

One of my favorite parts of portal work is the fact that most portal implementations touch a variety of technologies: different programming languages, a variety of internal systems and many different authorization and authentication mechanisms. One of the most common of these is LDAP, whether it be in the form of Active Directory or some other LDAP server.

Unfortunately, I have the same problem I'd like to think most techies have: if I don't work with something for 6 months or so, I tend to forget at least half of the important details. And since LDAP integration usually only happens every so often, mostly on new portal installs, I find I tend to forget the details only to have to re-learn them again.

Hopefully this post can serve as a reminder, and perhaps a primer for the uninitiated.

User Synchronization

For every user that logs into the portal, the portal has a record of their account in its PTUSERS database table. No matter that they are in Active Directory, LDAP, what have you, the user still must be listed in this table in order to log into the portal (basically meaning they are a user object in the portal).

The PTUSERS table is updated periodically by jobs run on configured authentication sources which essentially go out to an LDAP directory (or custom directory), ask for any new user accounts or groups and set them up in the portal.

One thing to note about this mechanism is that there is a time lag between when a user is created in a directory and when they can log into the portal. It would be nice if the authentication source were queried if the user was not found, and you can introduce customizations to do this, but OOTB you have to wait on the sync job.

Every authentication source in the portal also has an associated prefix, as well as a set of users and groups. The prefix is like (and can even be) a Windows domain. It is used to distinguish duplicate user names on different authentication sources.

A Quick Reference

Unfortunately, it can be highly confusing when you're trying to figure out what all the different user properties in the portal are, how they relate to LDAP/AD configuration, and what they actually mean. To that end, I have come up with the following table that (hopefully) explains each mapping in enough detail that you can see how it is built and what it is meant to do.

A couple of notes:

1. The help files on the authentication source configuration files are surprisingly helpful.
2. If you need to figure out your LDAP/AD structure, see user properties or run queries, I highly recommend this free tool: Softerra LDAP Browser.

See you next time.