Linking LDAP with other databases — design considerations [closed]

Question

There's a company X (a call center) with about 300 workstations and a task to implement LDAP for user authentication. Fine. We put non-volatile user information (UIDs, e-mails, first and last names) to LDAP directory – everything by the book. There are also several databases with information about calls, time management, etc.

By theory, these databases should have only one parameter in common with LDAP directory - the user ID (UID). In practice, to call a LDAP directory every time first and last names are needed (that is, almost every time some query results are displayed) seems to be inelegant. The second thought is to replicate some LDAP data in each such database. Or are there some other tricks? What is considered to be the best practices here?

This is a trivial task, and there must be hords of sysadmins who have done it before. I'm sure someone can share some relevant links.

Answer 1

We have done just this at my last job. It's one of the central concepts in identity-management. There are a very large number of ways to perform the attribute level synchronization you desire between various databases, some commercial, some open-source, some cooked up on the spot by technical staff.

Generally how it works is that you identify the attributes that need to move between various identity databases and figure out which database is considered the master for that attribute. You then tune your sync automation to propagate changes from the master out to the other databases, or if you wish it populate changes from secondary databases back to the master in some cases.

Unfortunately full blown IDM systems are rarely purely technical marvels. Since they often involve databases maintained by differing entities who probably do have differing business processes getting such large systems off the ground involves a large amount of manager-layer dickering.