Hi Jared,

I can only speak for myself (and I’m unfamiliar with LDAP and Active Directory) but would like to explore using EE as an intranet solution for clients. I’m probably underestimating the complexity involved, but I’d imagine a module that would allow an initial mapping of fields between user systems, then an initial import of members into EE’s member system,  followed by on-going synchronization at configurable intervals (I think nightly would be often enough for my clients…)  I would expect to use EE groups to handle permissions within the EE system. These groups could either be set up manually after an import to a default member group (ie “Employees”), or somehow map the outside groups to EE member groups in the initial setup. Again, I’m really not sure how possible it would be to create a module that would be generic enough to operate this way - as you say, it might have to be configures by an LDAP developer on a case by case basis.

Your thoughts?

You might be better off looking into OpenID and/or aMember (I know little of either one, but they are essentially solutions for what you describe).

The nice thing about LDAP is that it’s (supposed to be) technology-agnostic. You can query directory data that is organized in a manner that makes searching based on relationship much faster than a standard row-based table.

This isn’t always the case; as I mentioned, Active Directory and Novell’s eDirectory are not quite the same. Happens to be that VBA connects naturally to AD (big surprise), yet eDirectory querying seems to be impossible in VBA, as eDirectory does not map organizational units (OU) in a way that makes querying possible using VBA. If there’s a way around this, we (our LDAP guy and myself) were not able to find it. VBA LDAP errors are laughably bad, as well, so we were left guessing that was the issue.

I instead bring data from a POST call to a protected page on our website which outputs XML containing standard user data, which is then read by the VBA application on request (using XMLHttpRequest, the same ActiveX control that inspired Ajax).

It does no overwriting, though; it just fills in holes in identities (which can then be saved) and provides instance data, like if the person is still employed at the university or not. Our AD setup was still in flux at the time (we’re moving away from Netware), so this was the best and fastest solution. It was hard-won, let me tell you.

But, Active Directory is not supposedly technically LDAP either. They’ve made some changes to the functionality that make certain objectives easier for network administrators using Windows networking, that apparently make it difficult in other areas of programming that don’t need this functionality. This is the old “Microsoft does it their way, not the ‘standard’ way” thing. Some claim AD is not actually LDAP. I think it’s irrelevant.

In the end, LDAP on the backend is actually just a table with rows and columns. The way the data is stored is similar I think to things like Google’s Big Table, where it’s column-based instead of row-based. This is where the speed comes from, I imagine, although our LDAP queries (at my university) are actually somewhat time-intensive (in relative terms). Lots of queries to support, I imagine.

The results look pretty much like SQL results, so it’s not like there’s any magic there. Which leads me to the next question: Do you need LDAP at all?

We have two main eDirectory databases, one for authentication and one for identity. Originally, all there was was IDTREE, though; eventually authentications became too intensive for the IDTREE installation and they pushed that purpose to another mirrored directory with less data included.

But the reason for implementing LDAP was that our university needed a way to push data to a centrally administered (and by extension, limited) database to keep from allowing pulls from sensitive systems; it wasn’t so much to coordinate logins and profiles in the beginning, in other words. It was put together to prevent people from requesting direct access to the separate sensitive systems (like EIS and the class scheduling system), and oh by the way, why not synchronize passwords here too? Wonderful!

The reason I say this is that LDAP is not an identity cure-all. It makes certain things easier, but can be easily “misused” or misunderstood. Additionally, it can add complexity to some things which seem straight forward, such as:

1. Do you want password synchronization, or single sign-on functionality?
2. Are profiles copied (synchronized), or bridged (single profile instanced through reference) in all applications?
- 2a. If synchronized, do you allow for quarter hourly profiling?
- 2b. What about forced synchronization to prevent users waiting?
- 2c. If single profile, what to do with apps which are heavy on dispersed SQL statements which would need heavy rewriting?
- 2d. What about performance hits on bridging?
- 2e. If a program (like EE) allows for profile editing (“Let me change my name”), how will that work out?
- 2f. If it’s pulled from a central data repository, how do you distribute data that has been changed?
- 2g. How do you keep new profile data from being overwritten by old?
3. How do force all apps to behave in the same manner re: profile information?

Authoring an LDAP class is as simple as building a connection/binding/query service. It’s not hard; I’ve done it already (although I need to rewrite it). It’s not much different from relational databases in that respect, maybe a bit more limited in what it can do.

In the end, I think it’s that you need to engineer a solution that answers these questions, then see if LDAP is the best logical solution. Also, you might look into VMWare appliances, many of which come prebuilt with OpenLDAP and the synchronization has been managed. I have no idea if EE is supported by any, though. If you step into a solution that is managed, though, I think the writing will be on the wall already, which will make setting up EE more straight forward.

I want to just throw in another request for LDAP for Auth. progress.  Single Sign-on environments are not being considered for just uber large companies anymore.  With AD being relatively fully LDAP compliant for auth. queries, such a module, supported or not would spur the usage of the product incredibly.

In every facet I’ve gone to looking for CMS, DMS, Hardware, etc.  their forums are rittled with LDAP/AD, almost all maninly for auth. for SSO.

We have several rigged PHP code working now, but not in proper modular design.

Knowledgetree Community has integrated this into their product and have LDAP auth modules open that maybe someone could look at to help guide in the building for one.

Also, if you’re going to do it, be sure to include both TLS and SSL support.

Some claim AD is not actually LDAP. I think it’s irrelevant.

Because it is not and it is very relevant difference. Is SMTP your actual piece of mail or your ‘email storage’?
It is just a protocol or a pipe to AD database ...more info if needed.

For what is worth I second the need for LDAP integration…I would really like to have or buid an alternative (or in hand with) to Shareport and have small portal instead.

This would be very nice for EE popularity as now ‘people with budget & need to expand intranet’ are interested not just ‘bloggers’. Even just to have 1 directional/read querry of AD objects would be H U G E!
I can already see home made Help Desk apps, company directory lisitings, alternative to Advent line of products etc.

IMHO it would be quite alright to sell it as separate module due to its nature and usage.
Thanks for the post!

I guess I don’t understand your comparison. Active Directory is an implementation of LDAP, but is suitably different and contains a good deal more functionality than LDAP is meant (by design) to provide, ie, profile and object class-based data. It works for MS systems, though. Why argue?

I think it’s irrelevant, though, to argue the differences and get into “Why AD is not LDAP” as LDAP and AD are sufficiently similar that the *main* usages would easily be handled, ie, identity authentication for distributed computing.

Detection of AD or a different set of settings would need to be managed within the module/extension, though, to allow for LDAP-specific (OpenLDAP, eDirectory) and AD systems to work in the same module/extension implementation; otherwise, I believe you will need an LDAP and an AD implementation as separate functionalities.

For reference, a slide presentation of comparisons (the presenter concludes eDirectory is a better system, but the comparisons are valid):

http://www.mindworksuk.com/whichdirectory9-12.pdf

No argue or at least we are argueing the same thing for the benifit of EE.
I am just saying sounded you were approaching LDAP as if it actually stored something…as if it is a database. So when you said

But, Active Directory is not supposedly technically LDAP either

to me it sounded like

But, Earth is not supposedly technically flat either…

...well because it is not, it is a fact LOL. Sorry, laughing at my lack-of-coffee-interpretation of it not you.

LDAP is just that a protocol…it holds nothing it stores nothing…it provides hooks of communication…much like saying “I have my usernames stored in ODBC”....it doesn’t fly….you store things in some shape of DB and you ‘request’ things from that database by using some means of communication.

Now onto the stuff we all agree and that really counts
Yes you are right about LDAP and AD and needing to be treated as separate functions because LDAP can’t provide all the 100% features for AD controll…nor it should from security point….and because hooks that LDAP can use vary depending what directory is in the back end.

Detection of AD or a different set of settings would need to be managed within the module/extension

Exactamundo! Which why I suggested/requested if EE even goes this direction is should be on its own much like Forums are separeted from the Core and have their own sub-system of controll and parameters that can be easily set to choose connection to eDirectory, AD etc.
Not to say that even most people don’t need this in core package.

This is would be a very nice bridge to have when it comes to building corporate intranets and with Mulitsite manager being able to tie it in with your public realm. I think that EE would definetly open a door to more corporate implementations as well as small 5-10 staff shops.

Not to mention if there is a support for SNMP or small Syslog daemon….we could put some major web-app players out of business . OpenID would very nice as well.
Ok, too much coffee is not a good thing either.
All the best!

Hey, guys - please take this discussion (LDAP vs Active Directory) to private communications or to The Lounge.  Thank you!

Sorry got little carried away didn’t even realize it is pre-sale question.

Hi there,

why just stick with LDAP, I would vote for Radius (good for RSA, Vasco, eToken, ...) and plugin anything else there (LDAP, SQL, flatfile, ...).

Just my .02 EUR as an EE noob.

—Michael