Search results matching tags 'SharePoint', 'Authentication', and 'FBA'

FBA authorization fails when permission inheritance is cut

Tom — Fri, 03 Oct 2008 14:01:00 GMT

I experienced the strangest thing (read: annoying) with Forms Based Authentication.

This is the scenario:

We have a SharePoint Web Application with some Site Collections on it, using Windows Authentication (for internal employees). That Web Application is extended to a second Web Application, that one using Forms Based Authentication, with the accounts residing in a SQL Server database.

This is the problem:

When we add FBA accounts to subsites that have unique permissions (so inheritance is cut from the above site or site collection), it's not possible to log in. Basically, these FBA accounts are not known on the top level Site Collection. Authentication works (you can actually see: Access Denied, logged in as user ...), but authorization doesn't...

This is the solution:

We made an extra FBA Role, containing all the FBA accounts. Then we added that role to the top level Site Collection. Of course, we didn't want users to log in to our top level site. So we created a new Permission Level, having so little permissions, that logging in wasn't possible.

From then on, everything worked like a charm.

Keep on trucking
Tom

Alternate Access Mappings

Tom — Sat, 28 Apr 2007 05:13:00 GMT

Alternate Access Mappings (AAM) in SharePoint 2007can sometimes act a bit strange. It doesn't seem always be that logical. This is a real life example how I had to set up the AAM in order to meet the client's needs.

Situation:

A Intranet Portal, published on port 80, Windows authentication.
A second Web Application, which has been extended from the first one, on port 82 and configured to use Forms Based Authentication.

At that point, the AAM is setup as followed:
- Default zone: http://servername
- Extranet zone: http://www.trycatch.be

But, www.trycatch.be is not known be the internal DNS and will not be. It is used to publish the site to the internet.

Problem:

They wanted to make the Forms Based Authentication site also available from inside the domain, at a following way:
http://servername:82

The problem existed, that if you add and extra internal URL, on let's say an Intranet zone for http://servername:82, it gets redirected to port 80, getting that darn Windows authentication again.

Solution:

So, how do you set your AAM? Like this:

- Make you Default zone: http://servername:82
- Make in Intranet zone: http://servername
- The Extranet zone is still: http://www.trycatch.be

Then it's possible to access the Windows authentication and the Forms Based Authentication from the inside and the published outside.

Keep on dancing
Tom

Forms Based Authentication

Tom — Tue, 17 Apr 2007 09:54:00 GMT

There have been several blog posts about the implementation and the use of Forms Based Authentication in a SharePoint environment. Last two days I have been digging into FBA because there is obviously a growing interest among companies about this authentication method.

To start of I found a great help (must read!) in 2 posts by Dan Attis about setting up FBA and how to enable MySites and Personalization features for your FBA users:
Part 1
Part 2

Dan's primary purpose was about serving the customers, as in making the FBA part the most important one.
Well, I like to turn things around.

Situation:
You're working at a company with a bunch of freelancers. Let's say a newspaper. When a freelancer works for you, you would like to give him access to your SharePoint environment. Since you use a lot of freelancers (and not always for a long time) you don't want to put them into your Active Directory.

Setup:
You have an intranet portal. All your ("real") employees are registered in Active Directory and they are using MySites and Personalization features. Your freelancers don't need MySites nor Personalization features, since they are never long enough around to use them properly.

How to: (I will not go too detailed, since all the pure technical steps are beautifully described in the posts by Dan Attis)

Create a User database and some users.
Extend the already existing portal, creating a new IIS web site. (You can choose port and host header as you like)
Choose "Extranet" as zone in the Load Balanced URL section.
Add the connectionStrings entry and the Membership and Role Provider sections to the web.config file of the newly created Web Application AND to the web.config file of the Central Administration Web Application.
In the Central Administration web.config, change the default RoleManager to "AspNetWindowsTokenProvider"
In Application Management, change the Authentication Provider for the Extranet zone to Forms and enter the Membership and Role Provider names.

You're ready to go.

Thoughts and problems:

It is not possible to enable MySites and Personalization features for both Active Directory users and FBA users. That is because the SSP has to be changed to Forms Based Authentication itself. (In our situation, it wasn't required anyway ) It would require separate SSP's to accomplish this.
In our situation, the search works because it uses the Windows Based Authentication site to crawl. When going completely Forms Based, additional configuration would be required. But, searching into FBA sites (for example FBA Mysites) still causes problems.
User Administration. Well, you could write something yourself to access and administer the SQL Database. Or you could go to this link and use the webpart. Although it's still pretty basic, it has some cool features.

I've just begun to explore FBA, so probably more posts to come. So I give it a

To be continued...

Keep on rocking
Tom