WWW-Authenticate headers, preventing integrated authentication).
Whatever the reason, we need to figure out a way to utilize AD inside of SharePoint, instead of the usual reliance on browser headers. Fortunately, this is an easy process thanks to Forms-Based Authentication (FBA) using custom membership providers.
A core feature introduced in .NET 2.0, Forms-Based Authentication is a framework for managing user sessions via standard HTML forms and cookies. Using FBA, we can skin the login page however we like through the usual means (master page, themes, CSS) and it handles the tedious details of log-in validation, timing out, etc.
The killer feature of FBA is its ability to authenticate against various membership and role providers. Out-of-box support is included for a number of providers (including SQL and Active Directory). Best of all, you can also write your own when needed.
When it comes to integrating FBA and Active Directory authentication, the choice of provider isn’t completely obvious. Yes, there is a dedicated AD membership provider, but it has enough quirks that it’s sometimes preferable to query AD using the LDAPMembershipProvider instead. There are three common approaches:
Use the ActiveDirectoryMembershipProvider
Pros:
- It’s straightforward to set up. Check out this TechNet article for the required settings.
Cons:
- There’s no respective built-in role provider — I was surprised by this. ActiveDirectoryRoleProvider does not exist, so group- and role- based authorizations are excluded. Fortunately, this blog by Greg Martin and this article on the Code Project provide directions for writing your own.
- There’s also a known issue that prevents ActiveDirectoryMembershipProvider from working on the Default zone. That is, it won’t work unless you extend your application to a new zone. As Scott Hillier writes, it fails no matter what in the Default zone.
Use the LDAPMembershipProvider
Pros:
- LDAPRoleProvider is built in.
- It works seamlessly for any zone.
Cons:
- It’s a little bit more involved to set up. Thankfully, there’s are two great guides available: this thorough tutorial by my colleague Matt Morse and a guide on Code Digest.
- The built-in "Domain Users" group does not work when using the LDAPRoleProvider.
- The LDAPMembershipProvider is exclusive to MOSS (as a member of Microsoft.Office.Server.Security). It is not included with default WSS installs.
Write your own
Pros:
- You get precise control over security and performance. Sahil Malik made an argument for this scenario, along with source code for a custom provider.
- Custom handling means you can properly handle boundary cases, like the "Domain Users" group.
Cons:
- This is overkill for most situations. When possible, it’s better to use an existing solution than reinvent the wheel.
- As with all custom binaries, this adds the step of distribution to each WFE in the farm.
No matter which route you choose, there’s one caveat to be aware of:
Forms-Based Authentication suppresses NTLM authentication headers.
When using FBA, a user’s web browser is completely unaware of the usual NTLM token or Kerberos ticket. This means that if you use SharePoint as a front-end to another application which relies on AD authentication, the browser will still prompt for credentials when accessing the second.
If you ever need to provide unified AD authentication to separate applications using SharePoint as the front-end, you either need to stick with Windows authentication or use constrained delegation, using a tool such as Internet Security & Acceleration Server.
