Searching Information about OX-LDAP & OX-MYSQL

[swetter]

Hello!

I am searching more Information. Maybe it can be found on the website, but i did not find it in 2 Days of searching the site and the net.

What Kind of Information does OX save/get in/from LDAP? As far as i can see only the Addressbook is stored in LDAP, and as far as i red in the forum OX5 stores User/PWD in LDAP, but Hyperion does not.

What Kind of Information does OX save/get from/in MySQL-DB? As far as i can see all Groupware-Data is stored there and Hyperion stores user/pwds there. The existence of a configdb leads me to the assumption that some of the config is stored there, too.

Mails are not stored by OX, but OX is only Client of SMTP/IMAP-Servers?

Where does OX get User/Passwd from to authenticate itself to SMTP/IMAP-Server? As long as all of these three authenticate against the same backend, OX could save the pwd when logging in in a global Var, but where can i get this and what can i configure there?

The questions reason is one other question:

Is it possible to have a cost-free OX-installation (community edition) that authenticates against ldap without changing the source or not? And if so, where do i have to configure that sort of stuff?

Thank you very much!

[Martin Heiland]

Hi,

What Kind of Information does OX save/get from/in MySQL-DB? As far as i can see all Groupware-Data is stored there and Hyperion stores user/pwds there. The existence of a configdb leads me to the assumption that some of the config is stored there, too.

Correct, OX5 stores addressbooks as well as user authentification data to LDAP and some premissions are also handled by this backend. Hyperion does not store or ready anything from LDAP. All groupware, authentification and contact data is stored to the mysql backend.
The configdb is a central and unique information storage where groupware server(s) get information about storage backends, quota handling, context mapping and so on. It seems to not make sense to keep a seperate database for this at the first look. But when it comes to server clustering and multiple storage backends for different servers (for example), the configdb is the one and only point where all other groupware server get those information. Otherwise it would be redundant and more unflexible to manage.

Mails are not stored by OX, but OX is only Client of SMTP/IMAP-Servers?

Yes, OX Hyperion is only a IMAP/SMTP Client at the E-Mail module. That's caused by the philosophy to let the administrator chose the best backend for his environment as long as they are standards compliant. That means that you are not limited to one specific imap/smtp software which may even be implemented by the groupware itself. I believe the guys at cyrus, courier, dovecot (...) know best about IMAP practices and have a lot more experience for that kind of software. I guess in the future it will also be possible to abstract the E-Mail layer and get E-Mail information that is stored to databases to avoid scalability issues with imap/pop.

Where does OX get User/Passwd from to authenticate itself to SMTP/IMAP-Server?

Passwords at the database are not stored plaintext of course. That means on the other hand that the E-Mail server has to accept hash passwords to check them against a database or we have to get the credentials somewhere else. Actually the users E-Mail credentials are gathered from the login, the specific username for the IMAP Server is stored to the users table at the database.

For example:
Joe Doe logs in to the groupware webinterface as "joe.doe" with password "secret". The OX groupware server now checks the user id mapping for "joe.doe" and reads the field "imapLogin" and "smtpLogin" from the database. Those fields may contain a different username as some E-Mail providers use their very own mailbox name syntax. In our case, the login name for the IMAP and SMTP server is "jdoe@provider.com". The password from the webinterface login is kept untouched and is used in combination with the IMAP/SMTP username stored at the database. In our case, the groupware server will authentificate "joe.doe" as jdoe@provider.com and the entered password.

Is it possible to have a cost-free OX-installation (community edition) that authenticates against ldap without changing the source or not? And if so, where do i have to configure that sort of stuff?

Well. you've got the source, you're free to modify it
As far as i know there is no LDAP authentification plugin available at a default installaten, neither Community, Express nor Hosted Edition. Those plugins for integrating a 3rd party interface are delivered on request of a customer. I am no LDAP guru but i guess it is possible to add LDAP authentification by minor changes at the sourcecode. It would be nice to see such a plugin one day for the community editon.

Greetings.

[motin]

There seems to some sort of plugin for authenticating against LDAP, Database or plain text files at: http://www.open-xchange.com/wiki/ind...in_description

Haven't attempted to implement such a plugin myself yet - it seems quite experimental currently. I am very interested in ways to allow Hyperion to authenticate as well as store the address book against our existing OpenLDAP server...

Any reason to why Hyperion stores everything internally instead of through OpenLDAP? Are there any ways to get our existing OpenLDAP user to use Open Xchange's directory for authentication?

[Martin Heiland]

Hi,

there is a proper working and stable authentication plugin for LDAP available:

http://software.open-xchange.com/OX6/SP4/DebianEtch/all/open-xchange-authentication-ldap_6.6.0-7_all.deb

The cause why we store user data internally at the OX Database is simple: performance, simplicity and scalability. (open)LDAP is great for authentication but fails for storing large amounts of user data and retrieve them with a good performance. It would also add one subsystem to the list of required infrastructure components which means one more system to maintain. We also encountered some stability problems with openLDAP caused by the default berkelyDB. Last but not least, administration and maintenance of a LDAP directory service is one science for it's own, it would just increase the administration overhead.

Final conclusion: LDAP for authentication, databases for storing user data.

Greetings

[KermitTheFragger]

The cause why we store user data internally at the OX Database is simple: performance, simplicity and scalability. (open)LDAP is great for authentication but fails for storing large amounts of user data and retrieve them with a good performance.

Thats sounds rather odd IMHO, you are describing the sole purpose of LDAP: Storing large amounts of user data and retrieve them with good performance. LDAP directories are usually slower with write operations then RDBMS's and faster with read operations since the majority of the operations done on a LDAP server are read operations (A contact in an address book is more often read then it is updated).

Im no OpenLDAP specialist, but I do know that directory servers like Fedora Directory Server (The former netscape directory server and now opensource), Novell eDirectory, OpenDS (the opensource successor to Sun DS) and even Microsoft Active Directoy scale to millions and millions of user entries (and retrieve them with good performance ). It is the essence of LDAP.

It would also add one subsystem to the list of required infrastructure components which means one more system to maintain.

Most organizations already have an LDAP directory (Especially windows shops, which have Active Directory).

We also encountered some stability problems with openLDAP caused by the default berkelyDB.

I personally never had problems with OpenLDAP, but there are a lot of alternatives (as outlined above) if you don't like OpenLDAP.

Last but not least, administration and maintenance of a LDAP directory service is one science for it's own, it would just increase the administration overhead

IMHO the opposite is true; An LDAP directory server is usually THE authoritative server on user data within an organization. All other applications have to get their information from it somehow (This is especially true in a windows environment with Active Directory). Having a second database which you have to keep in sync with LDAP just adds administrative overhead.

BTW: If you want to smack me on my head, im usually also in the #openxchange channel on IRC

[Martin Heiland]

It's true that the Fedora directory server is a nice piece of software and LDAP in general is very powerful, yes - but openldap is far more spread through the distributions and we have had some bad experience with openldap on rhel/sles as it was used by OX5. I don't want to start a religious war about where to store user authentication and user data - but it's a matter of fact that it's more common to setup a database than setting up a ldap service. You're assuming that everybody already has a ldap service, this may not always be the case - especially not for businesses or organizations <50 users. I think that nearly every admin has already worked with a database for a webapp, but not everybody has worked with ldap. However, thats just my personal opinion. Remember that OX6 initially started at the hosting market, not at the 100-ppl-inhouse market.

Btw. is data replication/clustering with ldap as easy/effective/maintainable as with a rdbms? Serious question.

Try to imagine the other way around - why should anybody who does not have a LDAP, does not want any and does not know how to use it set up one for running a groupware? Just to read contact data from data source A and the rest of the data from data source B? Isn't data synchronization/backup a problem here?

If you have a existing LDAP - you can leave it like it is and use the open-xchange-authentication-ldap plugin to authenticate against your authoritative server without need to reconfigure it or something, this way of integration is more preferable than integrating a existing infrastructure to a groupware server (imho).

Greetings

[KermitTheFragger]

You're assuming that everybody already has a ldap service, this may not always be the case - especially not for businesses or organizations <50 users.

Its certainly true that not all organisations have access to an LDAP server, I personally think that most companies smaller ( < 20 ) probably don't have one. However I would guess that most SMB companies ( > 20 ) use windows with Active Directory. But that's just a gut feeling based on situations I have observed, I don't have concrete figures.

Btw. is data replication/clustering with ldap as easy/effective/maintainable as with a rdbms? Serious question.

Today even OpenLDAP has MMR support (yeah is going to be a cold day in hell ) replication is a standard feature of most LDAP directory server and usually doesn't require more configuration then to point the servers to each other. So clustering LDAP directories is (mostly) an easy task. But then again easy is a relative word

Try to imagine the other way around - why should anybody who does not have a LDAP, does not want any and does not know how to use it set up one for running a groupware? Just to read contact data from data source A and the rest of the data from data source B? Isn't data synchronization/backup a problem here?

If you have a existing LDAP - you can leave it like it is and use the open-xchange-authentication-ldap plugin to authenticate against your authoritative server without need to reconfigure it or something, this way of integration is more preferable than integrating a existing infrastructure to a groupware server (imho).

I think I need to clarify what exactly (I personally) would like (besides world peace that is ): I would like to have the OX user data in LDAP, I'm not really interested in storing the Address book contact information in LDAP. So the OX LDAP plugin eliminates this problem partly, but I still need to issue the following command to add a user to OX:

/opt/open-xchange/sbin/createuser -c 1 -A oxadmin -P secret -u testuser \
-d "Test User" -g Test -s User -p secret -e testuser@example.com \
--imaplogin testuser --imapserver 127.0.0.1 --smtpserver 127.0.0.1

This is the information I would like OX to get from LDAP; Things like givenname, surname, etc for OX users. Otherwise I have to sync this data between OX and LDAP.

So i'm not proposing to make LDAP mandatory, just to add a way that OX can use all the user information from LDAP.

[Daniel Halbe]

By the way it is possible to store the whole userdata in a directory service like OpenLDAP, eDirectory or Active Directory. We already have working enviroments with more than 10.000 users where the userdata are stored into OpenLDAP and synchronized with the OX Server.

At the moment this plugin is not released for the community edition but if you like I can bring you in contact with our partner who developed it.

Best regards,

Daniel

[KermitTheFragger]

Hi Daniel,

Thanks for the offer, but for us its not necessary. We are a small shop with only 20 people, full blown LDAP sync is more a nice to have thing (because I'm Lazy ).