MOSS 2007 Forms Based Authentication using AD LDS and Windows Server 2008

Forms Based Authentication is an attractive option for companies running MOSS 2007 because it means you can give partners and external clients access to your Sharepoint sites without having to give them a full blown Windows domain account, the only drawbacks being it’s quite tricky to set up and most people only see SQL Server as an option for a user store which gives complications with regards to maintenance of them users and less flexibility should you need to migrate them users to a full blown Windows account later on.

I am currently running MOSS 2007 on Windows Server 2008 and I wanted to implement Forms Based authentication using AD LDS as the user store instead of SQL Server. The benefit for using AD LDS as a user store is that it is built on the same enterprise level authentication server as Active Directory and comes with a user management application that will be familiar to most Windows administrators unlike SQL Server which can only be administered using the Web Site Administration tool that comes with Visual Studio. You can also easily migrate an AD LDS user store to a full blown Active Directory domain controller if that requirement should arise in the future.

I couldn’t find much on the web on how to setup and configure AD LDS with Windows Server 2008 and as It’s a fairly tricky undertaking I thought I would write an article to hopefully give a clear and concise step by step guide on how to get it up and running.

Installing AD LDS

To start off with I am assuming you have MOSS 2007 installed on Windows Server 2008 already so the first step would be to add the AD LDS role.

  • Open up Server Manager and click on the roles section to the left.
  • Click on the “Add Roles” link on the right which should bring up the “Add Roles Wizard”.
  • Check the box next to Active Directory Lightweight directory services and click next as shown below.

  • Follow the wizard until the end and AD LDS should now be installed on your server.

Configuring AD LDS

Now we have AD LDS installed we need to create a user store.

  • Open up Administrative Tools and click on “Active Directory Lightweight Directory Services Setup Wizard” to start the setup process.
  • Click next on the first page and you will be presented with the step below, make sure “Unique instance” is selected and click next.

  • On the next step give your user store instance a name as shown below and click next.

  • Now you need to give your instance a port number so you can access it, recommended to leave the default values here.

  • Now we need to create a partition for our user store. Select “Yes, create an application directory partition” and enter a valid X.500 AD partition name. Make a note of this Partition name as you will need it later on.

  • The next step is to tell AD LDS where to physically store your data.

  • Choose which domain account you want AD LDS to run under, I have left selected the default Network Service Account.

  • Next tell AD LDS which account you would like to give admin rights to.

  • The last step is pretty important make sure you select the MS-User.ldif file to import; this makes sure you have the User classes available within your AD LDS store.

And thats it you now have a AD LDS store setup. Then next step is to add a user to your store.

  • Under Administrative tool you will now see ADSI Edit application, open this up.
  • Right click on the ADSI Edit node and select “Connect to” you will see the “Connection Settings” dialog box shown below.

  • Enter a name for your connection in the Name box.
  • Under Connection Point enter your Distinguished Name into the “Select or type a Distinguished Name or Naming Context:” box. This will be the Partition name you entered earlier on when creating the user store.
  • In the “Select or type a domain or server” box enter you domain name and port number you setup earlier.
  • Click the Ok button and you should now see your connection under the ADSI Edit node.
  • You can now add a user by right clicking on the Users container and selecting New -> object.
  • You will be presented with the dialog box shown below. Select the user class and click next.

  • On the next screen enter the users username into the value box and click next, then click finish.

  • You now have a user in your user store, to set the users password right click on the user and selected “Reset password”.
  • One more step you need to take is to enable the user by right clicking on the user and selecting “Properties”.
  • Scroll down to the ms-DS-UserAccountDisabled property and change it to TRUE.

Extending your web application

Now we have our user store in place we need to tell Sharepoint that we want to allow access to our sites for these users. You will need a separate URL and web application so that MOSS can distinguish from internal and external users and present them with the right authentication mechanism. For example my internal URL is which will use Windows authentication and my external URL is which will use FBA authentication. Both URL’s point to the same SharePoint site but each use different mechanisms for authenticating users.

Our first step is to extend the internal application.

  • Open Central Administration and go to “Application Management”
  • Click on “Create or extend Web Application”.
  • Click “Extend an existing web application”.
  • You will be presented with the screen below.

  • Change the web application to your internal web application, in my case
  • Select create a new IIS website and enter a name.
  • Enter port 80 into the port textbox and your host header into the host header section, in my case, this will be your external URL.
  • Under the Load Balanced URL section make sure you change the Zone dropdown to Internet, this is very important.
  • Click Ok and you extended web application will be created.
  • Make sure you can navigate to your external URL, if you don’t get anything then make sure you have made the right DNS or Host file entries on your server.

Modifying web.config files.

At a minimum we need to modify the Central Administration and external web application web.config files you will also need to modify the SSP and MySite web.config files if you intend to use FBA with these services.

  • Open up your external web application web.config file and make the following entry just before the system.web node.

  • Be sure to change the connectionString attribute to match your own domain, port and partition name.
  • Now make the following entry inside the system.web node.

  • Change the connectionUsername and connectionPassword attributes to match your own credentials.
  • Save the web.config file and now open up your Central Administration web.config file.
  • Insert exactly the same entries in this web.config file as before.
  • Change the defaultProvider attribute of the roleManager node to AspNetWindowsTokenRoleManger, this is to ensure you can still access Central Administration with Windows authentication.
  • Save the web.config file and do and IISRESET for good luck.

Configuring authentication providers.

All we need to do now is tell Sharepoint that our external web application ( will be using Forms Based Authentication.

  • Open up Central Administration and go to Application Management.
  • Click Authentication Providers and click the Internet zone on next screen. You should then be presented with the screen below.

  • Change the authentication type to Forms and enter the Membership provider name and Role manager name from your web.config files in the respective boxes.
  • Make sure you select Yes under Enable Client Integration.
  • Click Save.

Adding FBA permissions.

Ok so now our external web application is using FBA and our Central Administration knows about our AD LDS store, we can now go ahead and add an FBA user to our web application.

  • Open up Central Administration and select Policy for Web Application.
  • Add a new user and you should now be able to enter an FBA user into the people picker box.
  • Once you have added a user to the web application policy you should be able to log into the internal web application using Windows authentication ( and begin adding your FBA user permissions to the site.

There you have it, It’s a bit long winded and a little tricky but pretty cool when it’s finally set up and working, trying navigation to you external web application ( and you should be presented with a FBA login screen.

kick it on

24 thoughts on “MOSS 2007 Forms Based Authentication using AD LDS and Windows Server 2008

  1. Hello Lee,

    I have been through your article and I must say I am very happy to have come across it as it is something that is very useful to me.

    I have a similar situation where my company uses MOSS 2007 as a local intranet system. We have an Active Directory Server (ADS) and internally all users using MOSS apps are authenticated using Windows authentication.

    We would now like to publish MOSS apps to the internet, for which the plan is to develop an ASP.NET 2.0 login page which would accept Username, Password and ADS DomainName (which as of the moment, the user uses internally). Using Forms based authentication and ActiveDirectoryProvider, this page would then authenticate these parameters against the ADS and return a true or false depending upon the authentication. In case if it returns a true, the user should be directed to the MOSS apps site.

    The above page has already been developed and works fine on its own (i.e. having a login.aspx page and then redirecting the user to a simple secure.aspx after successful authentication).

    However, when incorporating the changes described in your article above, there are a few questions that come to mind namely:

    1) Your reference to “External Web Application web.config” (in point # 11 under section titled as Extending your web application) means external web application developed in ASP.NET 2.0 right?? and not the External MOSS Application that is about to go public?

    2) Since you have talked about making changes to 2 Web.config pages i.e. “External Web Application web.config” and “Central Administration web.config”. I presume that both applications would be residing in separate folders and would have separate virtual directories within IIS. Am I right?

    3) In the External Web Applications’s web.config, you had mentioned about using ActiveDirectoryMembershipProvider, where you have hardcoded the username, password and domain. Why have you done that? In our scenario, How can we work around this so that the Username, password and domain entered by the user is authenticated?

    Well!! this is it for now…. I hope I have not bogged you down with too many questions.

    Hoping to hear from you.



  2. Hi Noel,

    1) The external web application referes to the extended MOSS web application created in the Extending you web application section.

    2) Yes thats right, once you have extended your internal MOSS web application another IIS site would have been created for the external web application.

    One thing to note here is although you have two different physical web applications in IIS MOSS will only show you your internal web application but with two zones, default (internal web app) and internet (external web app).

    3) To be honest I’m not sure why the username is entered in that web.config section I assumed it needed an authenticated user to connect to the user store. I would have thought it would use the MOSS system account otherwise, you may want to try turning on impersonation but I havn’t tried that in this scenario so won’t be able to help you much more there.

    Hope these answer your questions.

  3. Thanks SO much for this post!

    I’ve duplicated all these steps on a 2008 Standard box running in a workgroup. My only issue is that it would appear the web services do not authenticate with the AD LDS instance. I can use adsiedit and ldp.exe to hook to the instance with my administrator credentials but when I enter a username in the FBA I get an error stating that an “unknown username or bad password was used” it flags the line of code referencing the connectionUsername. I’m unclear as to whether I should be using the DN of a user in the instance or the credentials of the server *hosting* the instance. In either case I have tried both with the same results. I have created the user within the instance with a strong password and ensured that the ms-DS-UserAccountDisabled property was set (albeit I’m foggy on why this should be set to ‘True’).

    I really hope that you have some insight on this as it would appear this is the ONLY walk-thru on this (every other source just links you). I have searched forums in vain for the last 2 weeks (though my lack of using syntax correct searches may be to blame) and finally gave up with the hopes you may be able to shed some light on this!

    Thanks again!

  4. great work fantastic article but i am having some problems with it !!
    Let me explain you my scenario i am doing a POC for MOSS 2007 and ADLDS we have just one box for MOSS 2007 and ADLDS what i need is just to create one web application and enable ADLDS authentication as there is no domain and active directory at client side.

    I have followed your steps and i change the default authentication provider settings as well as i dont need to have two zones.

    but MOSS people picker is not picking the ADLDS user niether recognizing it. i dun know why

  5. Hi Lee,

    Thanks, for the great post.

    Need a little help. I got to the “Connection Setting” step, then when I click ok, I get an error message “Operation Failed. Error Code: 0x8007203a The Server is not operational.”
    – I made sure I specified the correct port, Distinguished Name, etc, but still get the same problem.

    Any suggestions will be helpful.

    Thank you again,


  6. Hi Lee,

    Are you running 64-bit? I’m wondering if you run 64-bit MOSS, if your FBA custom authentication provider needs to be compiled for 64-bit as well.


  7. I am also experiencing a similar issue described by Mike Stone and Ahmer Shahid. In fact, in my troubleshooting, I’ve concluded the following:

    The connectionUsername and connectionPassword attributes in the web.config file need to be set to an account created in AD LDS as instructed by Lee. Unfortunately, I get a different error message ONLY IF my settings are like this:

    The specified directory service attribute or value does not exist.

    The fact that this is a different error message tells me that my LDAP connection string and my credentials are correct. There is something else that’s preventing SharePoint from using AD LDS as a membership provider. There’s a KB article about this error message and double-hopping so perhaps a pre-reqquisite is that you need to have SharePoint operate under Kerberos and not NTLM. Will be testing this theory out shortly.

    If your LDAP connection string is correct AND the web.config credentials are not, this error message will be displayed:

    Logon failure: unknown user name or bad password.

    This scenario also occurs under the following scenarios:

    – LDAP connection string is correct AND the web.config credentials are correct AND ms-DS-UserAccountDisabled is set to TRUE.

    If the LDAP connection string is not correct, the following error message is displayed when entering credentials through the login form:

    The server is not operational.

    Lee, any help on this issue is greatly appreciated. Is your farm running under Kerberos or NTLM?

  8. Looks like I won’t be able to get Kerberos up and running in our test environment. From what I hear, there are AD stability issues with regards to REMOVING SPN’s from a DC operating in 2000/2003 mixed mode.

    I’m not sure what else to try… I might have to revert to my backup solution which is to use a SQL Server database as a membership provider.

  9. Hi Fred,

    I’m not sure why you would be getting these errors, I’m unable to look into it at the moment as I don’t have the install that I set up AD LDS on, I had to scrap it for a new project.

    I tried to write this guide as I was going along, but I know I was “fiddling” about quite a bit to get it working.

    If I get time soon I will try to set this up again on a new install and see if I get the same problems.

  10. Hi there, this article is just a guide to setting up AD LDS on Windows Server 2008, I did my best to record the steps I took to get this working.

    Also the article you linked too is talking about Windows Server 2003 and ADAM, this article details how to setup AD LDS on Windows Server 2008 which is slightly different.


  11. I am sorry but your articles if ull of dead ends, I spend two days following it and just got frustrated.

    You are missing key steps regarding permissions and configuration in LDAP to allow unsecure connections which are described in the following article:

    The most important is that using activedirectorymemshipprovider, you will not be able to look up users from SharePoint. PeoplePicker does not work.

    Here is what you really need to be using

  12. NaT – I ran into that same error message: 0x8007203a – “The Server is not operational” as well. When I created my first instance, I only had my partition, domain, and extension (i.e.:
    CN=SPFBAStore,DC=domain,DC=org). Every time I tried to connect to the store, it kept on trying to hit my domain controller.

    I went in and created a second instance which included the server that AD LDS is installed on and then it was able to connect up ok.


    I had to connect up using the non-SSL port though although my certificate should be installed correctly.

  13. I’m sorry if my walk through was not comprehensive enough or missed out some steps but I was basically writing this as I went along. I don’t have time to really hold other people’s hands on this as my full time job takes up most of my time.

    I wrote this article to HELP other people get on the right track, I had to figure most of it out myself and at the time of writing the post there was no other articles on the net about this so thought this may at least be useful to some people.

    You may have to go figure out some of the stuff on your own but hey thats what we are paid to do right?

  14. whoah this weblog is excellent i like reading your articles.
    Stay up the great work! You know, lots of people are hunting round for this info, you
    can aid them greatly.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s