Using LDAP Authentication With A SharePoint Intranet Is A Very Bad Idea

A couple of years ago I wrote an article explaining step-by-step how to integrate Novell e-Directory with SharePoint. At the time it was pretty much the only available information on the web. Since then I have frequently been asked for tips on integrating LDAP with SharePoint intranets, most recently last week. So I thought I would provide some updated advice:

Run away! Run far, far away.

1. Get one of your colleagues to distract your boss.
2. Climb out of your office window.
3. Head for the nearest bus, train station, or airport.
4. Change your name.

If somehow your boss or client finds you and demands that you integrate LDAP with the SharePoint intranet, explain why it's a very bad idea.

Why is it a Very Bad Idea?

 

From a technical perspective LDAP integration is really just Forms Based Authentication (FBA) - you are passing in a username and password to SharePoint, and these happen to be authenticated via LDAP calls to an identity store somewhere.

Using LDAP, logging into your SharePoint portal will look like this:

Doing this is a big mistake!

Reason #1: Time Spent Tinkering

Now in order to do this, there are a variety of technical steps you need to take. If you run into problems anywhere along the way, you will spend your valuable time trying to figure out if the problem is in your Role and Membership provider settings, in your various web.configs, your LDAP query, or something else you have to enable in SharePoint.

This means you are spending your effort (and your client or employer's money) struggling to implement something that with Active Directory would "just work".

Some might argue that this isn't a great reason - after all plenty of time and effort goes into modifying SharePoint to accomplish other requirements. But any effort you expend making SharePoint work without AD is time you could be spending modifying SharePoint to address problems the business actually cares about. The business does not care that its credentials are currently stored in Novell eDirectory and SharePoint prefers them in AD.

Reason #2: Your SharePoint Intranet Won't Work The Way You Expect

Portal users expect seamless integration and functionality when they are using SharePoint for the intranet, because that's what all the marketing materials teach them to expect.

Building an intranet without Active Directory can lead to some surprising and annoying side effects. Out of the box web parts or controls like the Organizational Hierarchy don't work very well without Active Directory. You can make them
work with ADAM or by exploring 3rd party replacements but you'll have to test any portal functionality you think you are likely to use.

Also, the user experience with Microsoft Office integration can become a problem. Open up Word or Excel when logged in using LDAP credentials and you might see this:

It's fun explaining that to an end user!

SharePoint Designer is also tricky - it wants to automatically authenticate you using windows credentials, and throws errors when it runs into forms based authentication.

I'm not claiming that these issues are insurmountable, but collectively they introduce new bugs, development, testing, and management issues, increase cost and risk, and potentially annoy your users. Is it really worth it?

How Is that Different from Internet or Extranet Environments?

Many extranet and internet environments use Forms Based Authentication without problems. Administrators or installers have to modify SharePoint to work in these zones using Role and Membership providers...So why is it ok for those environments to use FBA but not the Intranet?

Again, it's a question of user expectations. When a user logs on to an extranet or internet site, they don't expect seamless Office integration and automatic access to file shares using their desktop credentials. When they use SharePoint intranets, they do expect these conveniences.

All the literature and sales material tells them that they should be able to interact directly with SharePoint intranets via Outlook, Word, and Excel - without annoying popup boxes and workarounds. They expect to be able to use all of the out of the box controls and web parts like the Organizational Hierarchy, and don't want to hear excuses like "that works best with Active Directory so we can't use that now".

So What Should You Do?

I recommend synchronizing your e-Directory identity information into an Active Directory domain and building SharePoint on top of that.

There are a variety of ways to do this but one way you can investigate is via Novell's IDM which can synchronize between e-Directory and Active Directory.  Your e-Directory is still the master identity store, but any e-Directory changes get automatically sync' ed to the child Active Directory. Here's a link that might help: http://www.novell.com/coolsolutions/appnote/18349.html

You can definitely make SharePoint use multiple identity providers - but the reality is your SharePoint portal becomes much more flaky and expensive to manage. These days there are many ways to populate Active Directory from some other identity store - I always recommend that since it is less effort and risk down the road, and (probably) less cost as well.

SharePoint is complicated enough without adding to the challenges.

Of course your mileage might vary. If you have attempted (or succeeded) in integrating a SharePoint intranet with LDAP what were your experiences? Besides IDM, are there other good ways to synchronize Active Directory with a master identity store?