Skip to main content

Cloud

Issues with One User Store, Two Ways to Log In Using Custom Membership Providers

Here are the requirements:

  1. One user store, Active Directory in this case.
  2. Internal users (on the corporate network either physically or via VPN) will use Integrated Windows Authentication (aka the little grey box) to log into SharePoint 2007 server. Since they are already logged into the network they are somewhat "trusted" users.
  3. External users (accessing via the Internet and not in the above categories) will use forms based authentication that uses a custom membership provider due to the requirement for two factor authentication (something you know as well as something you have). The something that you know will be your Active Directory user name and password.

Here is the set up:

For demonstration purposes, we are going to ignore the fact that we have to do two factor authentication. We will simply use the built in ASP.Net AD membership provider and the built in forms login page to handle the external users. We can later change these out with our custom membership provider and custom login page.

  • Extend an existing web application onto a new web application to set up a second zone, with a different URL but the same port. For a good explanation of how to do this, please see Steve Peschka’s blog posting at http://blogs.msdn.com/sharepoint/archive/2006/08/16/702010.aspx. When you follow his directions, make sure you give the new web application the same port as the original web application but make sure you give it a different host header. This posting uses SQL server as the user store so once you start seeing references to SQL, you should refer back here to find out the XML that goes into the web.config files because we will use the AD membership provider as our user store.
  • Add the following XML to the web.config file of all web applications that you now have that need access to the new membership provider, either for actual log in or for the people picker. The stuff in red is the stuff to add and the stuff in black is just to give you a reference of where I added it into the web.config files. We need to do this so the People Picker on each site will be able find users in both the Windows Integrated Membership Provider as well as the new custom membership provider. You will have to customize some of it for your environment, specifically the LDAP string. This will be the original web application as well as the one that you just created from Steve’s posting above. Once you modify all of the web.config file, do an iisrest.

</configSections>
<connectionStrings>
<!– The connection string should point to the domain container since the Brookfield users will live in different OUs under the domain container.–>
<add name="AdConnectionString" connectionString="LDAP://<serverName>/DC=testdomain,DC=local" />
</connectionStrings>
<SharePoint>

<authentication mode="Windows" />
<membership defaultProvider=" AdMembershipProvider ">
<providers>
<!– Clears out the providers before you add a new one. –>
<clear />
<!– This AD provider maps the user name –>
<add name="AdMembershipProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" attributeMapUsername=" sAMAccountName" connectionStringName="AdConnectionString" connectionProtection="None" />
</providers>
</membership>
<identity impersonate="true" />

  • Modify the zone that you just created to change it to forms based authentication in central admin. You do this from the Application Management->Authentication Providers link.

  • Select the web application that you are dealing with. In my case it is htt://moss2007.testdomain.local. Then select the zone that you want to change. In my example I want to change the Extranet Zone.

  • On this page, you will select forms based authentication and fill in the name of the authentication provider that you configured in the web.config files. For my example it is AdMembershipProvider. Press the Save button once you are done.

You have now configured the membership provider(s) so now we need to give a user SharePoint permissions. This is where this approach starts to unravel a bit. If everything is configured properly, when you open up the People Picker in the internal URL site (in my case http://moss2007.testdomain.local) you should see the user there twice, once with a prefix of "domainName" and once with a prefix of "admembershipprovider:".

SharePoint thinks that the user from the integrated Windows provider is different from the one coming from the custom membership provider even though they live in the same user store. I am not sure that this is a good way to think about this. I can see some application where you would want to keep all of your users in one user store but possibly authenticate them a bit differently depending on where they are accessing the site from (internal vs. external).

In order to give that user access to both the internal URL and the external URL, we have to add both users to a SharePoint group. This could cause some administration headaches.

To test this (and please do), add only the "domainName" user to the SharePoint group and try and log into both URL’s. You should get the SharePoint "Access Denied" screen when you try and log into the external URL.

Note: When you try to log in to the forms based authentication on the external URL, you only have to enter in the user name since the AD provider already knows what domain it is pointed at. When you access the internal URL using Windows Integrated authentication, you will need to enter in the "domainName". Logging into this URL should give you the expected result, access to the site.

Now go back to the internal site and add in the "admembershipprovider:" user and see what happens. You should now be able to log into the external URL just fine.

This could cause a bit of a problem if you expected to only have to add the user in once because you thought that SharePoint would understand that the user was the same even though they come in through two different membership providers.

I have a call into Microsoft to see how we can meet the reuirements so stay tuned to see what happens…

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.

Dave Scheele

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram