orking with SharePoint can get complicated. Even seemingly basic tasks are wrapped up in so many layers of automation and support that it can be hard to sort out what you need to do to accomplish your goals. Trying to determine how to change the login page in SharePoint is no exception. For this reason you'll discover how you can modify an out-of-the-box login page to build your own, which you can customize as you desire—including associating it with custom code.
To be able to even see the login form you'll need to turn on forms-based authentication. There are several good resources that address turning on this feature, including Steve Peschka's post on the "SharePoint Products and Technologies Team Blog" and Andrew Connell's blog post, "HOWTO: Configure a MOSS 2007 Publishing Site with Dual Authentication Providers and Anonymous Access." These articles walk you through all of the details necessary to learn how to set up the secondary authentication (membership) providers and how to make them accessible. However, neither resource touches on how to modify the login page itself.
Layouts and Login
The out-of-the-box login page lives on the server as _layouts/login.aspx or on the file system in \Program Files\Common Files\Microsoft Shared\Web server extensions\12\TEMPLATE\LAYOUTS. This location makes the page an application page—one that lives outside of any single SharePoint site. This setup is both good and bad. It's good in that it works no matter what the site is or how the site has been provisioned. It's bad in that it doesn't use the same process for modifying a page that a regular SharePoint site page may use.
Because it's a friendly ASP.NET 2.0 application, SharePoint uses the master page functionality within ASP.NET 2.0. Within the context of a site the master pages are controlled at the site level. The master pages can be customized and updated to reflect the organization's own branding. However, being outside of the traditional site structure you're technically not able to modify the master pages that are used by the application pages in the _layoutsdirectory. There are two basic approaches to solving this problem.
The first approach is to create a copy of the LAYOUTS directory from \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE and place it underneath the root of the web site as a _layouts folder—or create the copy on the file system and define an IIS virtual directory with the name _layouts, which points to the copy of the files. While this approach technically works and does relieve the concern of having modified the _layouts directory, it inherently creates some problems—not the least of which is that it tends to break solutions packages that deploy new files in or under the _layoutsdirectory. This approach also has to be provisioned manually on each front-end web server because there's no automated process for doing it. And even deleting and recreating a web application can remove this virtual directory from IIS, leaving you with the original unmodified files.
A better approach is to create subdirectories under the LAYOUTS directory for your files. For instance, you might create your login page under a directory called DEVX. You can then reference a login.aspx page in this directory as _layouts/DEVX/login.aspx. It's a bit of a longer path, but ultimately it gets you to the same result and is more supportable because service packs and upgrades should leave your files alone. Further, you can deploy the files through a solutions package because they are in the _layoutsdirectory.
This approach doesn't work for every file in the LAYOUTS directory because many of them are referenced from SharePoint itself. However, web.configentries control the login page, and they can be changed to point to your new page.
For this discussion you'll use the second approach for the subdirectory (creating subdirectories under the LAYOUTSdirectory) rather than the first one because the second approach is more deployable.