Slinger's Thoughts

May 13, 2008

Host Header problems and FBA quirks

Filed under: SharePoint — slingeronline @ 11:35 am

Two for the price of one today! Now don’t you feel special?

Well, I decided that I wanted to add Forms Based Authentication to my sandbox server.  I’ve had it up and running for a bit now, but some of functionality I need to test for our external users as well as our internal users.  I figured it would be no big deal.  One of things I wanted to do, was to change the long membership string so that I could possibly try it on our production server as well.  When one of our external users logs in and happens to look at their settings, the name they will see at the top is “FBAAspNetSqlMembership:JSmith”.  Well that’s annoying to me.  So I wanted to change it.  This presented me with some new challenges.

I went through Andrew Connell’s FBA setup guide again, and followed each step.  When it came to naming the providers though, I wanted to change where he says “AcAspNetSqlMembership” to say simply “Members.”  It seems a bit more friendly.  So I made sure that all of my provider names matched appropriately.  He recommends you test the providers and make sure that they are working.  Well, I would like to, but there is no test button for the provider I created.  So I figured I would try out various combinations of what he suggested in his tutorial.  FBAAspNetSqlMembership, FBASqlMembership, ASPSqlMembership, Members, FBAMembers, SqlMembers, SqMembers, and a host of other combinations.  I found out that in order to be able to test the providers using the Asp Configuration interface, the provider name MUST have the letters “Sql” in it.  I’m going to test more later, to see if not including “Sql” will still function, but just isn’t able to be tested from this interface.  To be on the safe side, “SqlMembers,” and “SqlRoles” are my providers. On to creating my site collections.

Now here is something I was completely not expecting to happen.  When I first set up FBA on our production server, none of this happened.  I followed Andrew’s directions for creating a new Web Application, and creating a new site collection.  Shouldn’t hurt as there is nothing on this server anyways. It recently got reformatted, for other reasons unrelated to SharePoint.  My new emptytop level site has been created.  Empty?  Everytime I create a new site collection on this server, it is always empty.  It doesn’t matter what template I pick, there is nothing there.  There is no site to navigate to.  I can’t change anything if there is nothing to change.  I need to know how to fix this, in case it should ever happen on our production server.  That would suck. I tried deleting all of the site collections, and recreating them, same results.  Unless it was the original site collection created when I ran the set-up and configuration wizard, it is empty.  Doesn’t really do any good to have a site collection that you can’t do anything with.

After doing some research, I have discovered that it may be the host header that creates the problem.  Well, let’s try setting the host header in IIS after we create a new Web Application create a site collection. I imagine this would only be an issue when creating a new site collection as opposed to extending an existing one, but I will check that just to be sure.  So, I create a new WebApp with a host header set to “Test.”  Once I set up a site collection, my url should be http://Testand I expect that nothing will happen when I click the link. Yep, nothing. Now let’s try to set that Host header in IIS. (It has suddenly become painfully evident that I don’t know nearly enough about IIS.)  Well, that host header is set correctly.  I don’t need to change DNS settings since this server will be internal only, namely just me.  So I will update the servers Hosts file and see if that works.  I’ve edited the Hosts file at %windows%\System32\Drivers\Etc and added the servers IP address and the host name of my new site.  I navigate to http://Testand I get an authentication log in screen. This is a good sign.  None of my credentials are accepted though.  Not good.  At least I’m on the right track.  Any time that we create a new web application we will need to edit the DNS entry somewhere at least. If not network wide then at least on the server.  If we only edit the hosts file on the SharePoint server, we will only be able to access this site collection from the server itself.  DNS is the domain (HA!) of our Systems Administrator though.  I won’t bother him with this trivial thing.  Although I may need to, since I can’t log into the newly created Site Collection.  At least I have solved one issue. I know why I get empty sites when I add a host header into a web application.  Now that I have that matter sorted out. (I don’t have an actual resolution, but I know what the solution is, and it’s simple enough to get our Sys Admin to update the DNS entries on our Domain server.  All I have to do is ask him nicely. Now I need to check and make sure I don’t have the same issue when I extend this web application for the other Authentication provider I’m going to be adding.  Yep. I do.  So, when setting host headers, it’s not enough just to set them through SharePoint, but they needed to be added to DNS hosts entries as well. Or at least to the local machine’s hosts file. Damn.

  • Lesson 1. When you set a host in a web application through SharePoint’s Central Administration, either when you create a new web application, extend a web application or through an alternate access mapping, the DNS entry on the domain server must be updated to reflect that change in order for your site to be usable. 

Well, I’ve added my web application extension to my LMHOSTS file, but the limitation here is, as I’ve previously stated, I can only access my SharePoint sites from the server itself.  I won’t be able to navigate to it from elsewhere on the network.  Now let’s check out the forms based authentication membership providers and see how badly I can jack with the provider names before I break something.  This means that I will have to edit all 3 of my web.config files, and refresh the site I’m accessing fairly frequently.  But since I’m doing it, you won’t have to.

 Well I got past all of the weirdness that I was having with Forms Based Authentication.  (Couldn’t find the database, didn’t have permissions on the database, everything appeared to work right, but didn’t, all that typical nonsense that tells you that you screwed something up and so on.) Now it’s time to test out those provider names.  Please note that I am going to have to change those provider names in quite a few places, which is in the default web.config, the internet web.config, the central administration web config, and in the authentication providers section within the central administration site, under application management.  I’ll also change it in my original web.config that was created in the very first steps of setting up forms based authentication, so that I can keep track of my changes.  So that’s five different places I need to edit my provider names.  First I’m going to check what is says when I check the information under “My Settings” logged in as a test user.  It’s not pretty.  User information: testuser – fbaaspnetsqlmembershipprovider:testuser.  Ick.  I would love to trim that down some.  So here goes. Let’s change all of the configs to say something like “members.”   So, in all 4 web.configs, in two places per, and in my Authentication provider.  Once that is all set, a pre-emptive IISRESET, then close all internet explorer windows, and we will see what it says when I check the user information again.  Please note that all of my connection strings are still the same, I only changed what I named the membership provider, so it should still communicate with the database.  I shouldn’t have to remove and re-add a user.  Well, using “Members,” didn’t work.  I can sign in, but none of the permissions work correctly.  So let’s add “Sql” to the name of the membership provider and see what happens there. This was the hiccup when I was testing the providers using the Asp.net configuration utility, chances are that same limitation was passed on to SharePoint.  Just as a side note, I haven’t changed the name of the role provider, just the membership provider so far.  Another IISRESET and let’s see what happens.  Well, again, none of the permissions are working properly.  Although here is something odd.  I’m getting some new code added to my web.config files.  gets pasted behind the System.Web tag in each of my provider type definitions.  (I didn’t catch that the last time around, so let’s try “Members” again after I delete that extraneous code.  A little bit of research and it turns out that this is xml markup for a end of line basically.  That’s odd.  Same end results though.  Okay, so I’m going to put it all back together, and put that long provider name in again, and start over.  Well, the “My Settings” link is back, and the permissions work correctly again.  Something odd though.  I forgot to change the name of the membership provider in the central administration site, so it does not have the correct name for the membership provider, and yet everything still works.  This very likely won’t remain the case, so I do not recommend it.   And after all of that mess, I’m still stuck with how do you change the Account name display in “My Settings.”  I’m open for suggestions. 

Advertisements

5 Comments »

  1. Your not alone I’m having same problem. I changed the membership provider name. Changed all my web.configs, updated site collection adminstrator for all sites, and updated all the site provider authentications. My Settings disapears and had to change everything back.

    Comment by SharepointSucks — June 4, 2008 @ 4:19 pm

  2. Normally I create the DNS entries earlier in my installation, before actually creating the web application and entering the host name there, for the obvious reason that I want to be able to resolve the site from a client to test it right after I create it.

    Note: LMHOSTS is not really relevant to DNS; LMHOSTS is use for NetBIOS name resolution. Perhaps you meant the HOSTS file, which is used for local client DNS resolution.

    Comment by Perry — June 27, 2008 @ 8:49 am

  3. Perry, you are absolutely correct. Thank you for making that clarification for me.

    Comment by slinger — July 1, 2008 @ 6:38 am

  4. I found your site on technorati and read a few of your other posts. Keep up the good work. I just added your RSS feed to my Google News Reader. Looking forward to reading more from you down the road!

    Comment by AlexM — August 12, 2008 @ 7:22 am

  5. You have to do the following

    – set the membership configuration even in the SSP and central admin web configs

    – Do a user profile import

    – Do user profile sync in sharepoint through the already defined jobs or stsadmn : If both dont work (it wont) write custom code to sync the Moss site users with the imported users in MOSS while changing the display name/ full name to exclude the provider name

    Comment by Anoop Mathew — April 15, 2009 @ 12:02 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: