Ever wanted to provide clients or other external parties such as vendors, affiliates etc access to your SharePoint Sites without having to provide them with a Windows Active Directory Account? Luckily, SharePoint provides you with the ability to setup multiple authentication providers and in today’s post I will provide you with step by step instructions on how this can be easily achieved utilising Windows 2008 Active Directory Lightweight Directory Services (AD LDS) formerly known as Active Directory Application Mode (ADAM).
Previously, the most common method of providing Forms Authentication was to utilise the SQL Server membership provider which entailed running the ASP.NET SQL Server Setup wizard to configure your SQL server for application services, in our case SharePoint. My preferred method for extra security and flexibility is to utilise AD LDS, so let’s get to it.
1) Add the AD LDS Role to any Windows 2008 server
Click on Start / Administrative Tools / Server Manager. Click on Roles and then elect Add Roles on the right navigation pane. Check the box beside Active Directory Lightweight Directory Services then follow the wizard until the end. AD LDS is now installed and ready to be configured with your first data store.
In order to do so, click on Start / Administrative Tools / Active Directory Lightweight Directory Services Setup. The following setup wizard welcome screen appears. Click Next. 
Select A unique instance and then click on Next. 
Type in a friendly Instance Name. This will make it easier to distinguish down the track in the event you need to setup multiple instances for various applications.
Specify your LDAP port numbers and then click Next. Note that these numbers cannot be in use by any other application on your system. In my case I have specified 6000 and 6001 for SSL. 
Select Yes, create an application directory partition. Specify your Partition Name (keep this handy as you will need it at the end to connect the partition through ADSI Edit. Click Next. 
Select your File Locations. Click Next. 
Select Network service account. This should be sufficient in most cases. Select Next. 
Select your administrator account. Click Next. 
Click on the below options. This will be needed for your Extranet users accounts. Click Next 
Summary selections screen. Review and then click Next. 
Click Finish. 
You will notice that your newly created Instance (and other AD LDS instances for that matter) will now be listed under Programs and Features. This is where you will need to go in the event you want to remove that AD LDS instance at a later date. 
Now that our instance is complete, we are required to connect to this instance via ADSI Edit MMC snap in. Click on Start / Administrative Tools / ADSI Edit. Once the MMC is loaded, right click on the ADSI Edit Note and select Connect to…
Fill in the Connection Settings.
Name: Enter a friendly name
Connection Point: Click on Select or type a Distinguished Name and type in your Partition Name that you entered in earlier when creating the application directory partition (your wrote that part down like I told you, didn’t you?)
Computer: The machine that AD LDS is installed and the port number you specified earlier on.
Then click OK. 
Your User Store should now look similar to the screen below. 
We now need to create a container to store our users. This is equivalent to an Organizational Unit in Active Directory. Right Click on your CN entry and select New / Object and select your class as container. Click Next. 
Type Users as your value, Next and Finish 
We can now create our users in the “Users” container that we have just created.
Right Click on CN=Users and select New / Object, and select your class as user. 
Type in a user name. 
Right Click on your newly created user object and select properties. Scroll down and locate the msDS-UserAccountDisabled attribute and set it to False. 
Please note that if you have setup ADLDS on an existing domain, the password complexity requirements will be inherited from the Default Domain Policy and you may receive the following error after trying to apply any settings to that user account.
“Operation failed: Error code: 0x52d Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.” 
You will need to set the password by right clicking on the user object and selecting reset password. You will be prompted to enter and confirm the new password. 
2) Grant your SharePoint service account permission in the AD LDS store
Expand your AD LDS connection within ADSI Edit and click on the CN=Roles container. Right Click on CN=Readers listed on the right Navigation Pane and select properties. 
Locate the member attribute and select edit. 
Then select Add Windows Account and browse for your SharePoint Service Account and click OK. 
Wow, are we almost there yet? Well, for AD LDS we are. Now it’s time to focus more on the SharePoint side of things and Extend the existing web application to the Extranet Zone and set it to use Forms Based Authentication.
3) Extending your Web Application
Click on Start / Administrative Tools / SharePoint 3.0 Central Administration / Application Management.
Under SharePoint Web Application Management, click on "Create or extend Web application" Then Click on "Extend an existing Web application"
Select the Web application you would like to extend, and create a new IIS web site.
Enter port 443 and a host header which you can resolve via DNS, select SSL (you want to secure and encrypt your extranet zone for external access) and ensure your zone is set to Extranet. 
4) Authentication Providers
Again, under Central Administration / Application Management / Application Security, Select Authentication Providers.
Make sure the correct Web Application is selected and then click on the Extranet Zone
Select Forms as your Authentication Type and type in a Membership Provider Name (this can be set to anything) but will be required to be changed/match what you place in your web.config file. In my case I have set it to ADLDSMembership. Once you have made your changes, click Save. 
5) Modifying the web.config file for your Extranet Zone Site and your Default Zone Site
Here we need to browse to the location where our web.config file is located for the Web Site that we extended in step 2. By default, Internet Information Services (IIS) stores these files under
C:\inetpub\wwwroot\wss\VirtualDirectories\<Web Site Directory>
If you followed my example and specified a fully qualified domain name for your Host Header and a port number (443) the web site virtual directory will look something like this;
extranet.georgekhaliltesting.com443
The root of this directory will include the web.config file which you will now edit in your favourite editor (my case notepad) and insert the following entry just after your <system.web> node.
I have highlighted the variables in Red.
<membership defaultProvider="ADLDSMembership">
<providers>
<add
name="ADLDSMembership"
type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"
server="<servernamehostingADLDS>"
port="50004"
useSSL="false"
userDNAttribute="distinguishedName"
userNameAttribute="cn"
userContainer= "CN=Users,CN=SPFBAStore,DC=georgekhaliltesting,DC=COM"
userObjectClass="user"
userFilter="(ObjectClass=user)"
scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn" />
</providers>
</membership>
Code Friendly Snippet
<membership defaultProvider="ADLDSMembership"><providers><add name="ADLDSMembership" type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="SERVER" port="50004" useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="cn" userContainer="CN=Users,CN=SPFBAStore,DC=georgekhaliltesting,DC=COM" userObjectClass="user" userFilter="(ObjectClass=user)" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" /></providers></membership>
You will also need to add the below code for your People Picker to correctly pick up your AD LDS users. Kudo’s to Matt Morse on this one. You can read more about it here
<PeoplePickerWildcards>
<clear />
<add key="AspNetSqlMembershipProvider" value="%" />
<add key="ADLDSMembership" value="*" />
</PeoplePickerWildcards>
Save your web.config file (oh did I mention take a backup copy first before editing) and then run IISRESET to ensure all new settings have been applied.
I accidently omitted this step from my original post, however you will also need to modify the web.config file for your Default Zone (Windows Authentication) to allow you to add the ADLDS users to your SharePoint groups later in the process.
That’s it! Finally we got there. When an external partner browses to the extended website in the Extranet Zone they will receive the following SharePoint Forms Login Screen which will authenticate them against the AD LDS store that we have created specifically for this Web Site. When an internal user browses to the default site (Windows Authentication) they will not receive a login screen and will access the SharePoint site via windows integrated authentication.
If for some reason you don’t receive the above login screen but the dreaded SharePoint “Error… Troubleshoot issues with Windows SharePoint Services” something has gone pear shaped along the way.
Don’t forget, you still need to provide your AD LDS users access to your SharePoint site via Site Actions / Site Settings / People and Groups. It is easier to add your AD LDS users via the default Windows Authentication Zone. You will notice in the below screen shot that the people picker will display both Domain User Accounts and AD LDS Membership Accounts.
Now that our Forms Based Authentication model is now working for our External Partners to access our SharePoint site, are we able to customize the login page so it’s not so generic? Of course you can! But that will have to wait for another post….
In Summary, AD LDS gives organisations flexible support for directory enabled applications and as you can see we are able to successfully implement and integrate AD LDS with SharePoint. Lastly, AD LDS can also provide us with the same functionality as a full blown Active Directory setup without the requirement to deploy separate domains or domain controllers.