I currently have an LDAP database on my Suse 10.2 server for managing authentication and controlling emails for my Cyrus email server. I use this setup to provide email functionality to my web and email hosting clients, as well as DNS functionality, and it uses the default LDAP database that was setup when OpenLDAP was initially configured. Email support is working wonderfully, I might add.

I also tested and verified the use of an email lookup directory in two different email clients (Outlook and Evolution) so that I can tell one of my clients how to lookup the email address of users who are setup in the LDAP server, and it works beautifully. However, I'd also like to be able to allow my clients to build a shared contact database that can also be used in their email clients so that they can share them among all of their users. Ideally, I would need to be able to allow each client to have their own database of shared contacts, and I assume this would be done by creating a new LDAP database for each client company (i.e. group of users) that can contain the list of shared contacts for any of that client's users. When they configure their email client directory settings, they would enter the base path to their database in order to retrieve their shared contact database entries.

In my web searches, I've found plenty of CRM solutions on the web that claim to provide this type of functionality, but I believe that OpenLDAP contains everything I need to make this work without adding another layer of software to the server solution. (I subscribe to the "Keep it Simple, Stupid!" approach whenever possible.) Essentially, I need to have People entries in a client's LDAP database that are NOT email users on the system. The fields in the standard people schema are all the fields they would need - as long as I can figure out how best to add these non-user entries in the LDAP database.

Are there any potential difficulties in creating additional LDAP databases expressly for this purpose? Are there any tricks to adding contact entries into a client's LDAP database without them also being current email users on the server, so that those entries can be retrieved through an Email Client directory lookup?

I will also want to provide an easy method for my client users to add new entries to their LDAP contact database, most likely through a web interface for them that could then issue LDAP commands on the server based on the input fields for the new contact. (I don't believe this is possible from within the email client itself.) Is there any reason this could not be done with the proper configuration? What should I be aware of as I setup this contact management web interface? Is there a better way for non-technical client users to manage this list of shared contacts?

I hope that outlines what I want to achieve and some reasonable constraints. I look forward to any input.

Thanks,

Gene

Never mind - nothing like time to solve a problem for you.

I had created a secondary LDAP database prior to the previous post, so I decided to figure out how to add contacts through some effort. Yeah, I probably could have done that first, but in my own defense, I really didn't know if I was even on the right track.

For those who don't know the answer, once I read through some LDAP documents, I realized I could use the commandline (good old fashioned text prompt) LDAP cmds: ldapadd & ldapmodify with a properly constructed text file of info. So a little Googling found some example 'ldif' formats and the online docs for openldap.

A couple of quick commands later and I was creating imaginary people in the second database, but only after realizing that I first had to create the ou=people layer to put them in! Then I moved to my Outlook client and added another directory service pointing to the LDAP server with the new database as the BaseSearch path. It worked just the same as if they were email account users in the primary LDAP database.

I know I have some tweaking to do, but I've shown myself that it works. I also have to have a way that the client can manage their own contacts. Does anyone have any unvoiced concerns about this technique?

Thanks,

Gene

If it works well for you, how about documenting it for the rest of us? Sounds like it could be useful for others.

As soon as I finish working out all the management details and look into any security concerns, I'll do just that.

I'm still interested in any concerns or ideas that others on here might have about this approach, but I am encouraged by my success so far.

Thanks,

Gene