tech + caffeine = blog

Adventures In Search - Part 1 - What is Search?

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.

PTUSERS Column AD Auth Source Value LDAP Auth Source Value User Profile Value Description
NAME Auth Source Prefix + User Name Attribute Auth Source Prefix + User Name Attribute Display Name A "throw away" descriptive name for the user. Can be changed with a PWS or manually by the user.
MAPPINGAUTHNAME User Name Attribute User Name Attribute none A base mapping name for the user (without auth source prefix)
LOGINNAME Auth Source Prefix + User Name Attribute Auth Source Prefix + User Name Attribute Login Name The name a user has to type to log into the portal on the login screen (including the value that must be in the auth source drop down)
AUTHUNIQUENAME objectGUID in AD (not specifiable) User Unique Name Attribute (defaults to DN) Remote Unique Name A uniqueness constraint in the directory to tell the portal this is the same user, even if their login or name changes.
AUTHUSERNAME User Authentication Attribute (usually userPrincipalName to guarantee cross domain uniqueness - not sAMAccountName which is only unique in the domain) User Authentication Name Attribute (if not specified, defaults to DN - Distinguished Name) Remote Authentication Name The property used to authenticate the user with the directory. May not be used for authentication if an SSO solution is in place.

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.

Fork me on GitHub