Guys, I've created my web application using Form Based Authentication. I have separate database for this and I used email addresses as usernames. The problem is that whenever I sign-in or log-out the page and try to log-in again using the same account or different account, I now received this error: Error: * * * Go back to site Error: Access Denied Current User You are currently signed in as: wdavid@gurango.com Sign in as a different user * * * What do you think is the problem with this one. I am using the same account, I just log-out and wants to logs back in. This is the reference link I've used: http://www.andrewconnell.com/blog/articles/HowToConfigPublishingSiteWithDualAuthProvidersAndAnonAccess.aspx Please help, I'll reallyappreciate any suggestions. Thanks! // Willy David Jr

I am setting up a new MOSS 2007 site with 2 zones. One zone with windows authentication and another with forms authentication. I was able to successfully set up them both in a lab environment where the Databases and the SharePoint server were being hosted from the same server. However when I try to set it up in an environment where the Databases are on a remote machine I can get the Windows Zone to work fine, but the Forms zone won't work. I've modified the web.configs in all three zones (Central Admin, Forms Zone, and Windows Authentication Zone).The windows authenticated zone is working properly. When you go to the formszone you see the forms login page as expected. If you put in a bad password you get a "Password does not match" error. But if you put in a password that corresponds to a user you get logged in as that user, but then you are sent to a screen that says that user does not have permission to access the site (The same error that Willy David Jr is getting). We have tried giving that user access in 3 ways: We made that user the site owner in Central Admin We created a new Policy User and gave them Full Rights We added them as a site owner in the Forms zone. Each time we can resolve the user in the people picker, and we see that our provider is where the user originates. It is almost as if this is working halfway. The user gets authenticated, but they are not given proper permission. Any ideas as to what I can check would be greatly appreciated. If I can't figure this out soon we may try moving the Databases to the same server as the SharePoint server. Thanks for your help. Here is the procedure I am following: http://www.andrewconnell.com/blog/articles/HowToConfigPublishingSiteWithDualAuthProvidersAndAnonAccess.aspx Thank you, TimothyMasterson

Hey guys, yeah FBA is a PITA to say the least and from my experience MS has put 5 year olds on supporting FBA issues. So you are getting authenticated but access denied. I have run into this on a few sites for a variety of reasons. First of all. Configure a role in your role provider that encompasses all users. An equivalent to the NT Authority\Authenticated Users role. You will need this guy. Once he is set up go through your site and assign that role permissions in every MOSS group that the "NT Authority\Authenticated Users" group has rights. The biggest one that nails me is the Style Resource Readers group. That group will typically have limited access to your site which translates to read only type access to the master pages library and Style library. Other areas, potentially are in the service accounts you are using in your installation, however if one of those is causing the issue you would typically see something in your event viewer App or System log about someone being denied access to a something. The other place that would show up is the 12 hive log files. Usually when I see this error it is some ancillary resource the user accesses like a style page, custom page layout, custom welcome page, etc that is in a library that they simply do not have access to.

How do I go about "Configure a role in your role provider that encompasses all users."in my provider? I am using a SQL Provider. Do you mean just add a role to database and make sure every user has that role? Thanks for all of your help.

That is correct. In the SQL Auth sites I have used I created an "All_Users" group and ran a quick SQL statement to insert into all the users into that role.

Guys, Letmeshare my experience regarding Form Based Authentication. Followed the same steps mentioned in the Andrew Connell's Blog to achieve the same. But, i too get stuck at the same situation. Try to give the Secondary Administrator of the Web Application,the Full Access toSQL User store which was created by ASPNET_REGSQL.exe to store the user credentials. Folow the Steps: Grant the MOSS application pool account(Secondary Administrator) pool account access to the membership provider database. Grant the Secondary Administratoruser the following privileges on the ASPNETDB_MOSS_FBA database, and then click OK: aspnet_Membership_FullAccess aspnet_Roles_FullAccess Now follow the steps mentioned CentralAdministration regarding Policy for web aplications. For me its worked fine , after a great struggle for three days at the same point. No issues with Form Based Authutentication using SQL User Store -Vijay

The issue appeared to be that the port we set up the Forms zone on was being blocked which caused the credentials to not get through to sharepoint so we got the Access Denied Error. When we set the forms zone up on port 80 everything started working as Microsoft Advertised.

That is interesting. You were being authenticated, which was why it was logging you in as that user. That would seem to suggest that you were hitting the SQL DB when you were not on port 80. However, you are saying all you did here was switch the port, and it started working. That is weird, I would have expected you to never get past the authentication if that port was blocked. Any MS folks want to jump in here and may enlighten us to the reasoning on that? Assuming there are some who know anything about FBA.

Try the following steps if you have skipped them while doing FBA on your site:create the Full Rights policy Open your browser and navigate to the Central Administration Web site. Click the Application Management tab, and then click Policy for Web application. Ensure that the correct Web application is selected; it is displayed in the upper-right corner. Click Add Users. In the Zones list, click the zone, that you have specified earlier while extending the site. On the Add Users page, click the address book icon to open the People Picker dialog box In the People Picker dialog box, type the username (user from your membership datastore)in the Find box, and then click the search button. If you are getting the user thenthe configuration you created in the web.config file is correct. If not, there is a problem in the web.config files, which you must correct. You should also notice that the account name is displayed in the format that SharePoint uses internally to keep track of it: MembershipProviderName:accountName. In this scenario, that means the account name for username is fbaMembers:username. Double-click username to add it to the Add box, and then click OK. Select Full Control( if the same rights you have provided in the membership datastore) Click Finish to save your changes. The basic configuration is now complete; user should be able to log on toyour FBA site. you must access the extended site with the HOST HEADER NAME YOU HAVE PROVIDED FOR YOUR EXTENDED SITE.Both forms authentication and Windows users and roles can be added from either Web site. HOPE THIS HELPS.....ENJOY SHAREPOINTING... :)CHEERSSHEETAL

I did following to solve "Access Denied" issue in "Forms Based configuration" --- Go to : 1) Central Administration > Application Management > Policy for Web Application 2) Select proper Web Application (from top-right) 3) Click "Add User" (top-left) 4) Add required User or Role in it. 5) Grant it "Full Control" (as per requirement). Then its work fine for me !!! ~ Avinash

I fixed this.Use the standard instructions for dual AD/FBA membership that you find on the internet.Here is the key, that is not clear in most instructions:One of the Site Collection Administrators MUST be an FBA user. If you have similar names in AD and FBA, be CERTAIN that you select an FBA user. I use the little book icon and search to confirm the membership source.Until you do this, the system doesn't really "wake up" to the FBA system. People are recognized and can log in, but cannot get access to anything, regardless of SharePoint People and Groups settings.I recommend against all other suggestions on this list. Mostly I just want to be clear that I did NOT perform any other action on this list. In particular, I did not add any FBA users or roles to the Policy for Web Application. Add users to PfWA will "fix the problem", but prevents any user administration from Sharepoint, which is very important to me for FBA.

I have to say I'm running into the same issues.Yes, changing the user by doing this works: I did following to solve "Access Denied" issue in "Forms Based configuration" ---Go to :1) Central Administration > Application Management > Policy for Web Application 2) Select proper Web Application (from top-right)3) Click "Add User" (top-left)4) Add required User or Role in it.5) Grant it "Full Control" (as per requirement).Then its work fine for me !!! However, it's not really an acceptable solution. I can't manage the users that way, nor do I think it's intended to be used that way. Concerning One of the Site Collection Administrators MUST be an FBA user. If you have similar names in AD and FBA, be CERTAIN that you select an FBA user. I use the little book icon and search to confirm the membership source. My secondary site administratorfor the site belongs to my secondary role authentication (FBA Extranet zone), my primary belongs to the primary method using windows authentication. This still is not working for me. Any other thoughts?-UpdateI solved my issue. Just to get things straight, I was storing my users in active directoy, and then when I did the people picker it would default to using the DOMAIN/USERNAME instead of the PROVIDERNAME/USERNAME When I prefixed all my username with the PROVIDERNAME: it works just fine.

Check IIS and RoleProvider setup there, remove it if it's pointing to customized RoleProvider... Best regards