The steps in the most simplistic form are the following:

1. Create a forms-based\claims Web application to use an LDAP Provider using Central Admin

2. Configure the LDAP Web.Config files for the Central Administrator (web application), Security Token Service (web service), and FBA claims-based (web application).

3. Within User Policy for the newly created FBA\Claims Web Application, Add site collection owner and grant full control.

4. Finally, login to FBA site as site collection owner and grant user permissions to access site

We released a technet article “beta 2” version of how to accomplish this setup using the OfficeServer Ldap Provider. I created this blog in order to fill the gaps and provide some further insight on how to set this up properly. The technet article which covers the first two steps above is located here:

http://technet.microsoft.com/en-us/library/ee806890(office.14).aspx#section2

Note: This has been tested on Beta 2 version. I’ll update the blog when later builds are released to general public if changes are required.

 

FBA Setup Gotcha’s (three of them)

Gotcha # 1: Steps 3 and 4 are required

I will discuss steps 3 and 4 above in more detail now since they are missing from the article. Once you finish step 1 and 2 from the article, follow step 3 and 4 here:

 

Step 3 - Within User Policy for the newly created FBA\Claims Web Application, Add site collection owner and grant full control. Steps for this are the following:

1. Launch Central Administrator and select “Manage web applications” under Application Management

2. Select the FBA-Claims based web application and select User Policy from the ribbon

clip_image002

3. Select Add Users, select default zone and hit Next

4. Select the Address book button and add the site owner “Add the account under “User: ”

clip_image004

Note: These are both the same account. You are only required to add the account under “User:” since it’s the one enumerating via the LDAP provider.

5. Grant “Full Control under Permissions and hit Finish button.

 

Step 4: Login to FBA site as site owner and grant users access to the site.

1. Login to FBA site as site owner

2. Select Site Actions\Site Permissions

3. Select the Group you want

4. Select New, Add users to group and hit the address book

5. Select the ldap account, Add, and hit OK

clip_image006clip_image008clip_image008[1]

 

 

Gotcha # 2: Web.Config setup

The Technet article walks you through the setup nicely but a couple of things I want to point out. Mainly, misconfigured web.config files. First, treat each web.config file your configuring unique. Not all web.config files are the same. Don't copy output of one and paste it into another one and expect it to work.

Attributes to be aware of when configuring ldap provider in each web.config:

UserContainer - This attribute should look like: userContainer="CN=Users,DC=domain,DC=com"

If UserContainer attribute doesn’t contain a valid DN, you might see the following in the ULS logs during failed logon attempt:

12/29/2009 14:04:54.15  w3wp.exe (0x1118)        0x1374  Office Server     Shared Services                olgq       Exception                System.DirectoryServices.DirectoryServicesCOMException (0x80072030): There is no such object on the server.       at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext()     at System.DirectoryServices.DirectorySearcher.FindOne()     at Microsoft.Office.Server.Security.LDAP.FindOneObject(DirectoryEntry searchRoot, String filter, SearchScope scope, String[] propertiesToLoad, ResultPropertyCollection& entryProperties)     at Microsoft.Office.Server.Security.LdapMembershipProvider.GetUserAttributeBySearchProperty(String searchValue, String searchProperty, String returnAttribute)

 

groupFilter and userFilter - These two attributes sit under the LdapRoleProvider.

In the technet article, these use different filters within different web.config files.

For example:

Setting these two attributes in the Central Admin web.config looks like:

groupFilter="((ObjectClass=group)"

userFilter="((ObjectClass=person)"

Setting these two attributes within the Claims based FBA Web Application web.config looks like:

groupFilter="(&(ObjectClass=group))"

userFilter="(&(ObjectClass=person))"

It's easy to see the difference in these filters. If your ldap filters are invalid, you will typically get the following exception within the corresponding ULS log during a failed attempt to login via FBA:

12/29/2009 11:52:19.43  w3wp.exe (0x0B04)        0x0F28  Office Server     Shared Services                olgz        High                LdapRoleProvider.GetRolesFor() exception: {0}.System.ArgumentException: The (&(((ObjectClass=group))(member=CN=userx,CN=Users,DC=Domain,DC=com)) search filter is invalid.     at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext()     at Microsoft.Office.Server.Security.LdapRoleProvider.GetRolesFor(String userOrGroupDN, DirectoryEntry groupContainer, LdapDistinguishedNameManager ldapDnManager, List`1& userRoles)   

 

 

Gotcha # 3: Additional step required for Standalone installs

If you run through the above steps with Standalone installs, you need to add one additional step or you will see this in the corresponding ULS log during a failed attempt to login via FBA:

12/29/2009 11:50:02.81 w3wp.exe (0x1868) 0x1AB4 Office Server Shared Services olgq Exception System.DirectoryServices.DirectoryServicesCOMException (0x80072020): An operations error occurred. at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext() at System.DirectoryServices.DirectorySearcher.FindOne() at Microsoft.Office.Server.Security.LDAP.FindOneObject(DirectoryEntry searchRoot, String filter, SearchScope scope, String[] propertiesToLoad, ResultPropertyCollection& entryProperties) at Microsoft.Office.Server.Security.LdapMembershipProvider.GetUserAttributeBySearchProperty(String searchValue, String searchProperty, String returnAttribute)

One additional step is required and that is adding a couple of entries to the STS (Security Token Service) web.config file. You will need to add both connectionUserName and connectionPassword.

For example (see Red bold entries below)

  <system.web>
    <membership>
      <providers>
        <add name="membership"
             type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=94de0004b6e3fcc5"
             server="newyearDC.contoso.com"
             port="389"
             useSSL="false"
             userDNAttribute="distinguishedName"
             userNameAttribute="sAMAccountName"
             userContainer="CN=Users,DC=Contoso,DC=com"
             userObjectClass="person"
             userFilter="(&amp;(ObjectClass=person))"
             scope="Subtree"
             otherRequiredUserAttributes="sn,givenname,cn"
             connectionUsername="contoso\administrator"
             connectionPassword="password" />
      </providers>
    </membership>
    <roleManager enabled="true" >
      <providers>
        <add name="rolemanager"
             type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=94de0004b6e3fcc5"
             server="newyearDC.contoso.com"
             port="389"
             useSSL="false"
             groupContainer="DC=Contoso,DC=com"
             groupNameAttribute="cn"
             groupNameAlternateSearchAttribute="samAccountName"
             groupMemberAttribute="member"
             userNameAttribute="sAMAccountName"
             dnAttribute="distinguishedName"
             groupFilter="(&amp;(ObjectClass=group))"
             userFilter="(&amp;(ObjectClass=person))"
             scope="Subtree"
             connectionUsername="Contoso\Administrator"
             connectionPassword="password" />

      </providers>
    </roleManager>
  </system.web>

 

Good Luck!

Russ Maxwell, MSFT