Configuring MOSS for LDAP Authentication

Setting up forms based Authentication for MOSS is a way that you can allow external customers to login your MOSS sites or it also allows you to bind to your LDAP user store which is not AD. There were some challenges in setting this up but I want to lay down a post on how to enable this.

Our infrastructure is running on MOSS SP1. We currently have some web applications but are integrated via kerberos with internal AD. We wanted to bind one of our web application to our LDAP store (Tivoli Directory Services) and enable FBA. I wanted to create the web-app for the FBA users but internal AD users should also be able to use integrated authentication (NTLM) to get in. So that involves setting up one web-app and extend it to another IIS website on your webserver. So two IIS websites point to the same content, but different authentication and policies. You do not necessarily need to extend a webapp to enable FBA, but I just find it easy for internal users to login seemlessly. The steps are as follows

1. Create a webapplication which will be internal facing. This will be the webapplication that the internal folks will use with their default windows credentials. (say http://internal/)
2. Create a site collection in this webapplication for testing purposes.
3. On the central administration page - choose to extend an existing web application.
4. Make sure that the web application that is selected is http://internal/.
5. Give this extended IIS website a different host header which will distinguish it from the internal web app. For eg. external which makes the url http://external/
6. Map it to Extranet Zone.
7. Login to the server and take a backup of web.configs for central administration and the external web application web.config.
8. Modify the web.config as mentioned below.

We need to modify the web config for central administration as well as the extranet IIS website. Take a backup before these these changes. Open the web.config and locate the <system.web> element. Note the important attributes connectionUsername and connectionPassword. These attributes were made available as part of SP1. So, if you do not have SP1, the only thing that you can do is anonymous bind to the LDAP store. Copy the following configuration right below this element and save the files.

<membership defaultProvider="LdapMembershipProvider">

<providers>

<add name="LdapMembershipProvider" type="Microsoft.Office.Server.Security.LDAPMembershipProvider,
Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="server name" port="389" connectionUsername="DN of the user connecting to store" connectionPassword="********" useSSL="false" useDNAttribute="false" userDNAttribute="dn" userNameAttribute="uid" userContainer="user container" userObjectClass="inetOrgPerson" userFilter="(ObjectClass=inetOrgPerson)" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" />

</providers>

</membership>

Description of some attributes -

• defaultProvider - Name of the default provider. This needs to be unique and used in configuration in the central admin.
• name - This is name of the LdapProvider. To reduce confusion, this is named same as the defaultProvider because I have seen some sites mentioning to use the defaultProvider attribute in the UI and some saying to use the name attribute.
• server - Name of the server. We have used ip because the test LDAP does not have a dns entry.
• port - the port used by the ldap. By default this is 389.
• connectionUsername - the dn of the ldap user who can authenticate to the user store.
• connectionPassword - password of the user connecting.
• useDNAttribute - This is required to be false else logins may fail.
• userDNAttribute - the dn attribute of the user. It may vary for different stores.
• userNameAttribute - the user name attribute of the user. This can also differ.
• userContainer - The container within which users are present.
• userObjectClass - The class that the users instantiates.
• userFilter - The filter that will determine which users can logon.

Once these configurations are complete, sharepoint now has the information on which store to bind to and with what username.

1. Go to Application Management > Authentication Providers
2. Make sure that the right webapplication is selected. (http://intranet/)
3. Make sure that the Extranet Zone is selected.
4. Change the Authentication type to Forms. (We choose to do this step in UI. It is also possible to do this in web.config, but I prefer to do it here)
5. If you are not SP1 or above, this is the place where you enable anonymous bind by checking the check box.
6. Provide the membership provider name as in the configuration in web.config - LdapMembershipProvider. Click on Ok.
7. Now everything is set up. But we need a user to login to extranet side of the webapplication using FBA. There are two ways to do this. First, is to use the http://intranet/ to login to the site using integrated authentication and then add the FBA user. Second, Add the user using Web Application policies. I choose to do the latter but both are equally easy to do.
8. Go to Application Management > policy for web application. Click on add user.
9. Select the right web application and be sure to select the Extranet Zone.
10. Time for reality check - Provide the id of the user and resolve it. It should be underlined if everything is configured correctly. If it is not, then you need to check your settings in web.configs. Somethings amiss.
11. Give this user full control - this user will act as the owner of the external website.
12. Browse to the site collection that you created before, using http://external/ url. You should get a form login screen. This is a default MOSS screen which can be customized according to needs.
13. Provide the user credentials for LDAP and login to the website.

Thats all! You are now setup with two entry points to the site. You can now add other users who you want to access this external site.