FBA Users get Access Denied on Login when solution deployed

sharepoint2010
codeplex
#1
Hi,

We've upgraded one of our 2007 sites to 2010 via the content DB attach method, then converted it to claims based authentication and successfully setup FBA on the extended Extranet site. A selection of existing user accounts were tested to ensure they can log in and access the site, which they can.

When we then deploy the FBA Pack solution and try to login, user accounts that we tested and were working get Access Denied. Even if we elevate a user to Owner they still can't get in. Only making them a site collection administrator allows them access.

Anyone any idea as to what the issue is? There's no info in the event or SP logs to indicate the problem.

A new FBA user created via the pack with just member permissions can access the site ok. It seems the problem only affects existing accounts.

Any help suggestions would be appreciated.

Cheers,

Al
#2
Very strange. The FBA Pack doesn't do anything on deployment/activation that would change a user's permissions. That would have to be done on the FBA User Management / Edit User page (or directly on the SharePoint Site Permissions/People and Groups pages).

It does sound like a permission issue though, since assigning them as a site collection administrator does give them the appropriate permissions.

I would use the SharePoint Site Permissions Page -> Check Permissions option to check the permissions of an affected user that might give you a clue as to where they do (or don't) have permissions.

The only other thing I can think of in relation to the FBA Pack is to check whether you are using Membership Roles or SharePoint Groups to assign permissions. You can choose whether you're using roles or not in the Site Configuration page, then either Roles or SharePoint Groups will appear on the FBA Pack Edit User page.
#3
Thank you for the rapid reply.

I tried your suggestion and compared the permissions of the users who cannot access the site with those of the new user who can access the site, and found them to be identical. However the site I’ve been testing is a sub-site with unique permissions, and the test user who can access it successfully also has member permissions granted on the parent site.

Granting the other users who were getting Access Denied errors visitor permissions on the parent site means that they can now successfully access the sub-site in question. So it would appear that the FBA Pack requires the user to have some level of access to the parent site to function. Is this correct? And if so how do I get around it? As our current security model only gives users access to the sub-sites they require, not to the parent site directly.

Cheers,

Al
#4
I've verified on my own SharePoint installation with a site and a sub site, that you can indeed have a user with permissions on the sub site, but no permissions on the parent site.

My guess as to what is happening is that there's some type of resource on the sub-site page that actually resides on the parent site, and as such requires requires permissions on the parent site in order to display the sub site page (The resource may be an image, or perhaps the page accesses a list). As soon as you try to access a single resource you don't have permissions for, SharePoint will redirect you to the access denied or login page.

Maybe try creating a new blank empty team site to test the permissions with. If the resource that's getting accessed is accessed through the master page though (an image), you'll get the same issue. In that case you can run Fiddler, which should show you the last resource accessed before you're redirected to the access denied or login page.

Also, just to clarify, although the FBA Pack allows you to manage the permissions for FBA Users, it's SharePoint itself that actually enforces the permissions.
#5
I’ve created a new blank team site as a sub-site of the main site that I’m working on, using its own permissions rather than inheriting from the parent as per the other sub-sites.

As you suspected the permissions issue occurs within this site also if users attempting to access it have no permissions to the parent site. The (slightly edited) fiddler output from these attempted accesses is shown below. In both cases the authentication works and then redirects to the home/default page at which point Access Denied is thrown.

Result Protocol Host URL Body Caching Content-Type Process Comments Custom

13 302 HTTP <SERVER> /testsite/_layouts/Authenticate.aspx?Source=%2FTestSite%2FSitePages%2FHome%2Easpx 152 private text/html; charset=utf-8 firefox:5072
14 302 HTTP <SERVER> /TestSite/SitePages/Home.aspx 378 private text/html; charset=utf-8 firefox:5072
15 200 HTTP <SERVER> /testsite/_layouts/AccessDenied.aspx?Source=http%3A%2F%<SERVER>%2FTestSite%2FSitePages%2FHome%2Easpx&Type=list&name=%7B14414511%2DA24A%2D48AD%2D9118%2D43967AFB805B%7D 8,469 private text/html; charset=utf-8 firefox:5072

Result Protocol Host URL Body Caching Content-Type Process Comments Custom

7 302 HTTP <SERVER> /<SITE>/_layouts/Authenticate.aspx?Source=%2F<SITE> 137 private text/html; charset=utf-8 firefox:8100
8 302 HTTP <SERVER> /<SITE> 198 text/html; charset=UTF-8 firefox:8100
9 302 HTTP <SERVER> /<SITE>/default.aspx 387 private text/html; charset=utf-8 firefox:8100
10 200 HTTP <SERVER> /<SITE>/_layouts/AccessDenied.aspx?Source=http%3A%2F%2F<SERVER>%2F<SITE>%2Fdefault%2Easpx&Type=list&name=%7B38C7EB0F%2D4A12%2D4486%2DBC91%2DB2CF3CD2666D%7D 4,201 private text/html; charset=utf-8 firefox:8100

For the first site the list GUID in the access denied URL refers to the Shared Documents library of the sub-site, which is displayed on the Home.aspx page. On the second site tested the GUID refers to the Announcements list of the sub-site, which is on the default.aspx page. So it appears that users no longer have access to the lists in question on the site they are accessing, if the URL is correct in where the Access Denied is happening?

On investigation the permissions for both pages and lists appear to be correct, and as before a user with Visitor permissions to the parent site does not get access denied.

To further cloud the issue I un-deployed the FBAPack, and all users could then successfully access both sites. So I deployed it once again, and again this caused Access Denied to be thrown.

Somewhat confused by this.
#6
If you undeployed the FBA Pack and it worked, then the only thing I can think of is that the Change Password web part is on the page (or in the master page). If you navigate manually to a different page, does it work? How about if the user is an owner of the sub site, can they navigate to _layouts/settings.aspx?
#7
I've noticed I also get "access denied" for FBA users trying to access a subsite after activating the FBA feature at the site collection level. The subsite has unique permissions and doesn't inherit from the site collection, however, when I add the user to the site collection permissions, the user can get it. There is no content in the subsite that is being pulled from the site collection. Could this be caused by the fact that the FBA feature requires site collection access to show up? I'd leave it disabled for this site collection, however, users need the password reset button in the user drop-down. Any way to do this without activating the FBA feature?
#8
I think I found out why. It looks like the password reset page takes you to a page at the site-collection level. This means that users that we only want having access to a sub site and don't have access to the parent site collection get access denied when the FBA management pieces are enabled. Still trying to come up with a work-around for that.
#9
To ccoulson:

The Change Password web part isn’t on the page or master page (which we haven’t altered), it’s only accessible via the drop down menu under the users name.

Trying to manually navigate to another page throws Access Denied as well, even if the user is in the owners group they cannot access any page of the site. Even try to get to the _layouts/settings.aspx page throws Access Denied, though unlike the previous examples there is no GUID supplied in the URL to indicate where the error was thrown.

To tracerodgers:

Sorry that you’ve got the issue also, but slightly glad I’m not the only one! and yes I’ve noticed that when I access the Change Password with a user that has permissions it directs to the top level collection.

But I also tried editing the url so it read /testsite/_Layouts/FBA/ChangePassword.aspx and this successfully displays the change password page, but only to users who have permissions to the top level site.

Trying to figure out how to grant all FBA users access to the ChangePassword.aspx page.
#10
I've managed to reproduce the problem. The reason it worked for me before was because I had Anonymous Access on the site collection set to 'Lists and Libraries'. Even without giving anonymous access to the lists and libraries, this seems to give the user enough permissions to prevent this access denied error. You can use that as a workaround in the meantime. I believe the issue relates to the change password menu item.

I've raised the issue here:
https://sharepoint2010fba.codeplex.com/workitem/834
It will be in the next release - although I don't currently have a planned date for the next release. Probably 2-3 months down the road.

Also, there is a bug for the location of the change password page taking you to the site collection page instead of current site page. The issue is here:
https://sharepoint2013fba.codeplex.com/workitem/3

It will also be in the next release.
#11
tracerodgers: as for your question about only activating the change password menu without adding the rest of the features - this is also something that will be looked at for a future version:
https://sharepoint2010fba.codeplex.com/workitem/832
#12
awesome thanks for looking into these! look forward to your next release.
#13
Got the workaround in place and the users who were getting access denied can now access the site.

Unfortunately when any of these users then try and access the change password option they get Access Denied at this point.

It would appear to be due to the change password link redirecting to the parent site as:
http://<SERVER>/_Layouts/FBA/ChangePassword.aspx causes Access Denied

whereas

http://<SERVER>/testsite/_Layouts/FBA/ChangePassword.aspx is displayed successfully.

As before if a user has visitor permissions on the top level site the Access Denied error does not get thrown.
#14
Yeah, that's the bug here:
https://sharepoint2013fba.codeplex.com/workitem/3

The change password page uses the url in the FBA Site Configuration page, so as long as everybody can access testsite/_Layouts/FBA/ChangePassword.aspx, you can change the url to that.

Or you can create you own change password page, give everybody access to it, and change the url to that.