I needed to integrate content from a back-end system with an anonymous, public SharePoint site. The back-end system came with web parts for the purpose, but trusted that SharePoint had authenticated the user and simply pulled that logon name to pass through the web part to the server for access control. This was an issue because the anonymous site by definition had no logged-in user. The back-end system also had an anonymous capability, but the system administrator was not comfortable turning it on for fear of inadvertently exposing confidential data (and rightly so). In short, my “anonymous site” needed to be logged in as some actual logon account. This had to happen behind the scenes without prompting the user for credentials. It was time to hit Google.
I found a number of articles on the web with similar-but-not-quite-the-same needs. I also found these articles sometimes making things more complicated than it seemed it should be. Well, after a lot of reading and much trial and tribulation and lots of errors, I eventually found something that worked. I will give you step-by-step instructions, but first I will give you with a little background. I have always found it a good idea to try and understand what I am doing rather than blindly following a recipe, so I will try to explain how this works.
Generally speaking, SharePoint is configured to use the authentication mechanisms built in to Windows, i.e. Active Directory integration. There is another supported mechanism called forms based authentication, usually abbreviated as FBA. When using FBA, you can specify custom authentication providers. There are a few built in providers, one of which is Active Directory (AD). Why would you turn on FBA only to use AD? Keep in mind that there is only ever one authentication provider being used within a SharePoint site zone (a URL, this will be explained); you can’t use Windows and Forms authentication at the same time. With Windows authentication, I could not find a straightforward way to override the integrated security to log in as someone other than an actual Windows-authenticated user. Even Microsoft articles pointed me in the general direction of FBA. So the AD provider via FBA is what I have used, and in fact thus far it appears to be working for me just fine.
Now about those SharePoint zones… You can “extend” a SharePoint application from Central Administration. Among other things, when you do this, you must select an unused zone (there are five all together). SharePoint will create a new IIS site for each such zone you extend into, each with its own URL, web.config and app pool process, but serving pages from the same content database. The authentication provider is defined in the web.config for a site (zone). So extending the site into a new zone gives you the option of logging into the site with ‘normal’ integrated Windows authentication using one URL, and having completely different authentication for users coming in through another URL. I recommend you maintain a SharePoint-standard, Windows-integrated zone so you can easily ensure you have administrative access to the site, restorable through Central Administration settings if necessary, without the complications of a custom authentication configuration. It can also simplify problem-solving if you do run into issues with the non-integrated authentication.
- The existing Windows-authenticated site: internal.example.com
- The new FBA-authenticated site: external.example.com
Extend the web application
- Open Central Administration and select Application Management.
- Click Create or extend Web application, and choose Extend an existing Web application.
- Make sure you have the proper Web Application selected, i.e. internal.example.com.
- Choose to create a new (IIS) site called external.example.com.
- You can use the same port 80, but be sure to add the host header for external.example.com.
- Update the path if necessary for your standards. You will need to know the path for later steps.
- Leave NTLM as the provider; leave Allow Anonymous set to No.
- Set Zone to Internet. Note: you can use another zone, just make sure you pick the same one throughout these procedures.
- Click OK and wait for the site to be created.
Set up a new provider for the extended site, and for Central Administration
- Open the web.config for external.example.com (located in the path you set when extending the app).
- Find the <PeoplePicker> element and add this as a child node.
<add key="MyADProvider" value="%" />
- Add the following just above the <system.web> element. You should of course change some-dc to an appropriate domain controller.
<add name="MyADConnection" connectionString="LDAP://some-dc" />
- Add the following just above the <authentication mode=”Windows” /> element. connectionUsername and connectionPassword are for an account that can read Active Directory. If the application pool identity for this app can already do that, you can omit these attributes. However, be sure to leave the other attributes in place.
<add name="MyADProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionUsername="someusername" connectionPassword="somepassword" />
- Now make all the changes you just made to set up the new provider in the web.config for external.example.com to the web.config for Central Aministration. This will allow Central Administration to find users that belong to the new provider.
Set up forms-based authentication
- Back in Central Administration Application Management and click Authentication providers.
- Make sure internal.example.com is the selected web app (see the upper right part of the page).
- Click the Internet zone.
- Change Authentication Type to Forms.
- Uncheck Enable anonymous access.
- Enter MyADProvider in Membership provider name.
- Click Save.
- Go to Central Administration Application Management and click Policy for Web application.
- Make sure internal.example.com is the selected web app in the upper right.
- Click Add Users.
- Make sure internal.example.com is the selected web app and choose the Internet zone.
- Add an administrative logon and give it Full Control, then click Finish.
- You should now be able to log in to external.example.com and authenticate as the (internal) administrative user you just added.
- You can now add users and grant permissions as always. The difference is that you can now add users from either the Windows or the FBA provider. It can be confusing when the FBA provider is also Active Directory, as in this case. When selecting names use the People Picker as it will show you the account name prefixed with MyADProvider: on the Account Name column.
- You can also modify the User Information List view to display the Account column, which also displays the prefix.
- Note that you cannot use wildcards in the People Picker to locate FBA users – you must enter their full logon username to “find” it.
- Add an FBA user and make sure you can log in as that user.
Override the SharePoint login to use a specific user
- Make sure you have a working FBA-enabled extended site before going any further.
- In Windows Explorer, navigate to TEMPLATE\LAYOUTS inside the 12-hive folder; by default the full path would thus be C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS.
- Create a new folder we will call ext. You should make the name something non-obvious as it will be a valid URL that can be seen in the HTTP headers when a user accesses the site.
- Create a new empty text file in ext and rename it extlogin.aspx. Note the relative URL of this new file is thus /_layouts/ext/extlogin.aspx.
- Now save the following code in extlogin.aspx, substituting somelogon and somepassword with the credentials of the user to be logged in.
<%@ Page Language="C#" MasterPageFile="/_layouts/simple.master" %>
<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Import Namespace="System.Web.Security" %>
<%@ Import Namespace="System" %>
public void Page_Load(object sender, EventArgs e)
<asp:Content ID="PageTitle" runat="server" contentplaceholderid="PlaceHolderPageTitle" >
Let me see your identification.
<asp:Content ID="PageTitleInTitleArea" runat="server" contentplaceholderid="PlaceHolderPageTitleInTitleArea" >
This isn't the page you're looking for.
<asp:Content ID="Main" runat="server" contentplaceholderid="PlaceHolderMain" >
- In the web.config for external.example.com, set this custom page as the default login page, like this:
<forms loginUrl="/_layouts/ext/extlogin.aspx" />
- Close all browsers, then open external.example.com. The site’s default page should open and assuming the site is a standard SharePoint template, should show somelogon in the upper right. If it takes you to the extlogin.aspx page then the login failed and you should double-check all the steps above, and the status of the somelogon account to be sure it is not locked or disabled. Also be sure that you added the MyProvider:somelogon user and not the NT Authority\somelogon user.
That should be all you need to do to get a site to automatically log in a particular user. You’re done!