Skip to main content

Cloud

Forms-Based Authentication options for Active Directory

A common request when working with MOSS is to use Active Directory for authentication, but hide the implementation for end-users. This might be a design decision to hide the clunky modal dialog boxes that prompt for NTLM / Kerberos credentials. Or it may be a functional requirement (e.g.: some proxies mishandle 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:

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:

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:

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Bert Johnson

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram