Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

closed as off topic by Zoredache, RobM, Ward, Shane Madden, Scott Pack Oct 4 '11 at 2:05

Questions on Server Fault are expected to relate to professional server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

    
First of all, LDAP isn't a database, it's an access protocol. Second, the question you are asking seems to me like one far more suited to software engineers than systems administrators. –  Matt Oct 2 '11 at 15:22
    
Sorry, bad wording in the headline indeed. –  badbishop Oct 2 '11 at 17:39

1 Answer 1

We have done just this at my last job. It's one of the central concepts in . 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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.