Step by Step – Configure SharePoint 2010 Forms Based Authentication with ADLDS

Note: Discuss artifacts discussed in this article from Here.

It is very common to use Active Directory Lightweight Directory Services – ADLDS in Windows 2008 environments (ADAM in Windows 2003 environments) to store external users in extranet environments for physical separation of the internal and external users. Typically external identity systems require specific schema changes and AD administrators don’t allow applications to store their users in the main organization domain directory for security concerns.

Recently I was able to successfully configure SharePoint 2010 Claims based authentication for the ADLDS using Forms based authentication. This article describes 5-Steps guide to configure ADLDS in Single-Server SharePoint 2010 environment on Windows 2008 R2 server for Forms Based Authentication in non-SSL environment. You can easily adopt this guide to use in SSL environment.

Note: If you are looking for detailed step by step guide with lots of screenshots, you can download 55-pages step by step PDF guide demonstrating same steps discussed in this article.

Step 1 – Configure ADLDS Environment

 Step 2 – Create New Web Application with Forms Based Authentication

  • Add DNS entries for the host headers (e.g. adldsportal.niks.local)
  • Create New Web Application with Claims Based Authentication
    • Specify Port-80 and Host Header (e.g. adldsportal.niks.local)
    • Select Windows Authentication and Forms Based Authentication
      • Specify Membership Provider – LdapMember and Role Provider – LdapRole
    • Specify proper content database name and leave everything else as it is
    • Create New Site Collection and specify Niks\Administrator as Site Collection Admin
    • Verify the Windows Authentication by logging to http:\\adldsportal.niks.local as Using Niks\Administrator

Step 3 – Grant “Application Pool” accounts READ Permission on ADLDS instance

  • Add Content SharePoint Web Application “Application Pool”, Central Administration Web Application “Application Pool”, and Security Token Service “Application Pool”  accounts READERS Roles on ADLDS instance. This would allow SharePoint to browse ADLDS store in least privileged scenario.
  • In My Sandbox, both ADLDS Administrators and SharePoint Application Pool accounts are same so, there is no need for explicit setting of permissions but in real world least privileged environment, these application pool accounts will be different and must be granted permission on the ADLDS. Failure of granting permissions for STS application Pool account may cause login failure issues. Failure of granting permissions for Web Application Pool accounts may cause people picker failure.

Step 4 – Update the Web Config Files for FBA – Content Web App, Central Admin Web App, and STS

  • Follow Mirjam’s blog, it works – http://sharepointchick.com/archive/2010/05/06/configuring-claims-and-forms-based-authentication-for-use-with-an.aspx
  • Before you make any changes, Please make sure to have a copy of all the original web.config files before making changes.
  • Please note that these web.config entries would work for ADLDS Containers, ADLDS Group Objects, and ADLDS Users Objects. If you are using either OUs, Persons, or other ADLDS objects, please modify the LDAP membership and roles providers entries as needed.
  • Content Web App Configuration
    • Update adldsportal.niks.local web application web.config – C:\inetpub\wwwroot\wss\VirtualDirectories\adldsportal.niks.local80\web.config
    • Replace the  <PeoplePickerWildcards> entry with following XML
<PeoplePickerWildcards>
<clear />
<add key="AspNetSqlMembershipProvider" value="%" />
<add key="LdapMember" value="*" />
<add key="LdapRole" value="*" />
</PeoplePickerWildcards>
  • Locate the <membership> entry and Replace everything from <membership> to </membership> with the following XML
<membership defaultProvider="i">
<providers>
<clear />
<add name="LdapMember" type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="SP2010VM.niks.local" port="52983" useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="userPrincipalName" userContainer="CN=WPSCN,O=NIKSADLDS,C=LOCAL" userObjectClass="user" userFilter="(ObjectClass=user)" scope="Subtree" otherRequiredUserAttributes="cn" />
<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</providers>
</membership>
  • Locate the <roleManager> entry and Replace everything from <roleManager> to </roleManager> with the following XML
<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">
<providers>
<clear />
<add name="LdapRole" type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="SP2010VM.niks.local" port="52983" useSSL="false" groupContainer="CN=WPSCN,O=NIKSADLDS,C=LOCAL" groupNameAttribute="cn" groupMemberAttribute="member" dnAttribute="distinguishedName" userNameAttribute="userPrincipalName" groupFilter="(ObjectClass=group)" userFilter="(ObjectClass=user)" scope="Subtree" />
<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</providers>
</roleManager>
  • Central Admin Web Application
    • Update Central Admin Web Application web.config file (to find central admin web.config – go to the IIS, select central admin, and click Explore to find contents)
    • Replace the  <PeoplePickerWildcards> entry with following XML
<PeoplePickerWildcards>
<clear />
<add key="AspNetSqlMembershipProvider" value="%" />
<add key="LdapMember" value="*" />
<add key="LdapRole" value="*" />
</PeoplePickerWildcards>
  • Find the <system.web> entry and add the following XML directly below it. By default, there should be 1 blank Membership or RoleManager entry. Double check whether the <membership> and <rolemanager> entries only exist ones. Delete any double entries.
<membership defaultProvider="i">
<providers>
<clear />
<add name="LdapMember"
type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
server="SP2010VM.niks.local"
port="52983"
useSSL="false"
userDNAttribute="distinguishedName"
userNameAttribute="userPrincipalName"
userContainer="CN=WPSCN,O=NIKSADLDS,C=LOCAL"
userObjectClass="user"
userFilter="(ObjectClass=user)"
scope="Subtree"
otherRequiredUserAttributes="cn" />
<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</providers>
</membership>

<roleManager defaultProvider="AspNetWindowsTokenRoleProvider" enabled="true" cacheRolesInCookie="false">
<providers>
<clear />
<add name="LdapRole"
type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
server="SP2010VM.niks.local"
port="52983"
useSSL="false"
groupContainer="CN=WPSCN,O=NIKSADLDS,C=LOCAL"
groupNameAttribute="cn"
groupMemberAttribute="member"
dnAttribute="distinguishedName"
userNameAttribute="userPrincipalName"
groupFilter="(ObjectClass=group)"
userFilter="(ObjectClass=user)"
scope="Subtree" />
<add applicationName="/"
name="AspNetWindowsTokenRoleProvider"
type="System.Web.Security.WindowsTokenRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</roleManager>
  • Modify STS web.config file
    • From the IIS, select the SecurityTokenServiceApplication under SharePoint Web Services and click Explore – it should take you to the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken
    • Find the </system.net> entry and add the following XML directly below it
<system.web>
<membership defaultProvider="i">
<providers>
<clear />
<add name="LdapMember"
type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
server="SP2010VM.niks.local"
port="52983"
useSSL="false"
userDNAttribute="distinguishedName"
userNameAttribute="userPrincipalName"
userContainer="CN=WPSCN,O=NIKSADLDS,C=LOCAL"
userObjectClass="user"
userFilter="(ObjectClass=user)"
scope="Subtree"
otherRequiredUserAttributes="cn" />
<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</providers>
</membership>

<roleManager defaultProvider="c" enabled="true">
<providers>
<clear />
<add name="LdapRole"
type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
server="SP2010VM.niks.local"
port="52983"
useSSL="false"
groupContainer="CN=WPSCN,O=NIKSADLDS,C=LOCAL"
groupNameAttribute="cn"
groupMemberAttribute="member"
dnAttribute="distinguishedName"
userNameAttribute="userPrincipalName"
groupFilter="(ObjectClass=group)"
userFilter="(ObjectClass=user)"
scope="Subtree" />
<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</providers>
</roleManager>
</system.web>

Step 5 – Configure the SharePoint Authorization and Verify the Access for the both AD (Windows) and ADLDS (Forms Based) Users

  • Verify ADLDS Users and Groups are available to test
    • Sample Roles – adldsowners, adldscontributors,adldsreaders
    • Sample Users – adldsowner,adldscontributor,adldsreader and add them to specific groups
  • Verify AD Groups and Users are available to test
    • Sample Global Security Groups – adowners,adcontributors,adreaders
    • Sample Users – adowner,adcontributor,adreader
  • Verify that central admin people picker finds for both AD groups/users and ADLDS roles/users – Please note that ADLDS roles can be searched with the full role name while ADLDS user names can be searched via wildcard
  • Configure AD Groups/Users and ADLDS Roles/Users Membership to the SharePoint Security Groups – Readers, Contributors, and Owners
  • Verify that AD users and ADLDS users added in SharePoint Security Groups via AD Groups/ADLDS Roles have proper access – read-only, contribute, full control

Following screenshot demonstrate that I was able to successfully login as ADLDS User – WPSCNAdminUser

More Resources

Advertisements
This entry was posted in SP2010 Admin General. Bookmark the permalink.