Friday, February 20, 2009

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:

LDAP Signin - Additional Zone

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:

LDAP Word Integration Problem

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:

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?


  1. clear, frank, objective. very nice. Thanks.

  2. Dear Nick,

    Your article "how to integrate Novell e-Directory with SharePoint" is great. I've sucessfully imported users into SharePoint from eDirectory. However,I'm not able to import Groups/Roles. Could you please give me a hint about how to do it? You can email me to I'm looking forward to hearing from you and thanks in advance.


  3. Hi Nick, your proposition about LDAP+Sharepoint is interesting enough. I'm in the situation where my Sharepoint is in a PERIMETER network and it needs to authenticate users against a DC in INSIDE network. In this case using LDAP is the only choice? there is a way to access from sharepoint the INSIDE Active Directory while preserving the PERIMETER isolation?

  4. Hi anonymous, I'm afraid I'm not an expert on that sort of setup. However these tips might help you. Normally the SharePoint in the perimeter network would have its own AD Domain, with a one way trust to the inner network DC. Here are some links on this: and
    However if you are unable to even install a one-way trust domain in your perimeter network then I believe LDAP is your only remaining option.
    A related question is, where is your SharePoint database server residing?

  5. Sorry George, I just saw your comment. I've sent you an email.

  6. Hi Nick,

    I am interseted to know the answer to George's question can you please post your answer in this blog.


  7. Dear Nick,

    Thank you for your explanation.
    You said " I recommend synchronizing your e-Directory identity information into an Active Directory domain and building SharePoint on top of that"
    I have a question about this procedure.
    How to configure the client stations to get the connection with the Microsoft AD domain (add computer to domain) if Novel is the active authentification mechanism for them.

  8. This comment has been removed by a blog administrator.

  9. most moronic post I heard in years "with Active Directory would "just work". "

    I prefer the challenge to understand what is happening over "just work".

    Im in the sad situation to deploy MOSS&AD into my heterogene network. Using LDAP is way more better to maintain then telling AS where a Unix-user can find his shell.

    though thank you for some hints

  10. Thanks sunta, I'm glad I made it to the top of your list of most moronic posts. Please let me know if it is "Most Moronic Post 2010" or "Most Moronic Post of the Decade" so I can celebrate.

  11. Nick, I'm glad I found your Article here, as an extension to your setfous article about sharepoint and edirectory LDAP. I looked at your article in septembr, because I started thinking about How I could use Office Webapps, sharepoint 2010 and my edirectory running on OES2 SP2. In fact, from what I read above, thats exactly what you tried to do, and your article addressed all of the pitfalls...I work in a school division with over 31 schools...and now I am re-evaluating my apprach based on what you wrote..

    And indeed, when I posed the Sharepoint, office webapps and edirevtory/LDAP scenario to the microsoft gurus, I received simular information to what you have presented...without the possible pitfalls, so I am gretful for findinf this:

    Anyways...I don't know where this leaves me brcause i cant afford idm...damn..its an AD world...any suggestion...junping out a window sounds good right now....

  12. Thanks for the feedback anonymous. If you can't create an AD sync then you might have to go down the LDAP route (although I would really try to make the business case for setting up AD first). Be aware that this post and my articles refer to using SharePoint 2007 and not SP 2010. In 2010 there are a number of improvements to the authentication model which may make this a better experience (using Claims Based Authentication). Additionally I believe the Office 2010 integration will be better (if you have that) and the Office Web Apps should help too. Hope that helps.

  13. Thanks Nick, I'll do a test and see how it goes, but i'll keep my mouth shut until I know all the problems...because once its rolled out...its hard to go back...

    I can't wait to try the office online webapps. I'll let you know how my ldap adventures/test goes.


Note: only a member of this blog may post a comment.