This project is read-only.

Access Denied at Configure Site

Nov 23, 2010 at 3:47 PM

I am getting access denied at step 4.1 of the installation - Configure Site Directory Site. This happens regardless of the credentials I set, whether it be SPSetupUser or any famr administrator.

I have completed step 2.9 - assuming that the Central Administration Site to deploy to is denoted as the server name:port number for the central admin site. I used all content sites.

It appears I am not the first to come up against this problem. Has anyone found a solution yet?

 

Thanks,

Mar 4, 2011 at 3:00 AM

I am getting same here access denied at the same step.  Anybody help

Thanks
Peter

Mar 9, 2011 at 4:38 PM

I m facing the same issue. I follow all installation steps. The solution is deployed on all Web applications (and admin central  web application). I am getting an access denied error when i try to configure "site directory site". I use a farm administrator account.

It seems we are many coming up against this problem.

Thanks

Manuel

 

Apr 20, 2011 at 8:30 PM

Same here.  I receive the error "This not a valid site directory. Specify a URL to a site that is using the site directory template". 

When I check  Central Admin > System Settings > Manage Farm Solutions > microsoft.mcsuk.spsitedirectory2010.wsp, the status is deployed and the target site is in the list of sites "deployed to".

I would love to check this feature out... anyone have a fix for this?? Thx ~ pj

Apr 21, 2011 at 1:02 PM
Edited Apr 21, 2011 at 1:08 PM

I am facing the same access denied issue.

My account is in the Farm Administrators group, Solution is deployed to all web applications.

Regards

Mike

Apr 21, 2011 at 1:16 PM

Folks,

I am sorry to hear that people are having trouble with deployment. It looks to me that a bug has been identified.

I guess the question is what are you guys doing differently compared to others that have deployed without issue.

Could you all answer the following:

1)      Are you using ‘least privilege’ accounts

2)      Are you using Kerberos

3)      Has the solution been deployed explicitly to the central administration web application or did you select ‘all content web applications’

Apr 21, 2011 at 1:31 PM
martinkearn_msft wrote:

1)      Are you using ‘least privilege’ accounts

2)      Are you using Kerberos

3)      Has the solution been deployed explicitly to the central administration web application or did you select ‘all content web applications’


1) UAC is turned on.

2) I am logging on using my regular account (authenticated against our Active Directory), my account is a member of the following groups on the server "Administrators", "IIS_IUSRS", "WSS_ADMIN_WPG", "WSS_RESTRICTED_WPG_V4", "WSS_WPG"  My account is a member of the SharePoint group "Farm Administrators"

3) On our test server we have only two web apps, the solution is listed as deployed to both. I can't remember the order of deployment I have tried deploying and retracting lots of times now.  I will retract from all and try again.

Regards

Mike

Apr 21, 2011 at 1:39 PM

Please make sure you specifically deploy to central administration. I have a feeling that "deploy to all content web applications" does not do this as CA is not a content web application.

 

Apr 21, 2011 at 1:44 PM
martinkearn_msft wrote:

Please make sure you specifically deploy to central administration. I have a feeling that "deploy to all content web applications" does not do this as CA is not a content web application.

 


I can confirm that "deploy to all content web applications" does not deploy to the Central Admin (CA) web.

I have now tried the following :-

  • Deploy to all, then deploy to CA
  • Deploy to CA, then deploy to my content web app
  • Deploy to my content web app, then deploy to CA

All give the same result.

Apr 21, 2011 at 1:46 PM

Hi, is there any way that you can turn UAC off and try that?

Just trying to eliminate possible causes.

Apr 21, 2011 at 1:50 PM

I deployed the directory with my SP Farm account, which is a domain account. I was only able to work around the issue when adding my personal domain account to the Farm Admin group. My personal account (domain account) would then allow me access to the Directory Admin features, but my SP Farm account still could not gain access. I never figured out the difference from there. This is as far as I went with it, I hope it helps.

Bill Runion

Apr 21, 2011 at 2:31 PM

I deployed twice- once to all applications and once again specifically to Central Admin.  I'm not using Kerberos and have no idea what least privileged accounts means.  I'm wondering if my error is different from others since I get "This not a valid site directory. Specify a URL to a site that is using the site directory template" no matter where I point to.

 

Thanks for developing and troubleshooting ~ pj

Apr 21, 2011 at 2:33 PM
martinkearn_msft wrote:

Hi, is there any way that you can turn UAC off and try that?

Just trying to eliminate possible causes.


Turned UAC off (and bounced the server)

Still the same :-(

Apr 21, 2011 at 2:35 PM
pjaxon wrote:

I deployed twice- once to all applications and once again specifically to Central Admin.  I'm not using Kerberos and have no idea what least privileged accounts means.  I'm wondering if my error is different from others since I get "This not a valid site directory. Specify a URL to a site that is using the site directory template" no matter where I point to.

 

Thanks for developing and troubleshooting ~ pj


I got this the first time, there are TWO Sharepoint Directory options in the console, make sure you chose the second one (at the bottom of the page) titled "SharePoint Directory 2010"

May 3, 2011 at 10:37 AM

Hi Martin,

I am back from my holiday, is there any progress on understanding how to "fix" the problem?

Regards

Mike

May 3, 2011 at 12:44 PM
Edited May 3, 2011 at 3:13 PM

Hi Martin,

I have just managed to deploy the Site Directory to another server and I have got it to work.

The working server "machinea" has the following web applications :-

The failing server "machineb" has the following web applications :-

On machinea I can successfully configure the site directory.

Once I created a non secure site on machineb I can then set up the site directory inside the new non secure web app.


Edited to change the order of web apps to reflect actual order.

May 3, 2011 at 1:02 PM
Edited May 3, 2011 at 3:13 PM

Hi Martin,

On machinea I can't swap the configuration from web app "A Web App on 9176" to web app "Sezz Web App on 9999", when I try to swap it in the configuration screen I get the access denied screen.  The /sites/SiteDirectory Site has been set up in both web apps.

If I then go back in to try to configure it again I then get the access denied message.

I can get rid of the access denied message if I go to configure scan job and set the web app back to web app "A Web App on 9176".  Trying to set the change the web app in the configuration screen has partially succeded in rippling the changes.

Regards

Mike


Edited to reflect newer information

May 5, 2011 at 2:55 PM
Edited May 5, 2011 at 2:57 PM

Hi Martin,

Getting a much better picture of things now.


I checked all the site collections on the web application on port 9999 on machinea and found my account was not set to either primary or secondary administrator.

Having done that I can now change the selected web application to either of 9176 or 9999.

So there is most definateley a security issue here.

NB: It will not be practical for this to be the permanent work round.


In light of the above I made sure I was either primary or secondary administrator on all site collections for the https site, but I still can't select it's web app, without the access denied message.

Regards

Mike.

May 12, 2011 at 8:24 PM

Same issue here, has anyone found a workaround? Same access denied error every time when I try to access the "Configure Site Directory Site" page in central admin.

I have tried different combinations of deploying it to Central Admin and other web apps. 

Mike: Could you explain that workaround a bit more? I'm not understanding what you wrote. You made sure your account was an admin on all site collections within the web application, and then you were able to set up the site? When I tried this, I still get the error.

 

Sean

May 13, 2011 at 9:41 AM
SeanMArthur wrote:

Same issue here, has anyone found a workaround? Same access denied error every time when I try to access the "Configure Site Directory Site" page in central admin.

I have tried different combinations of deploying it to Central Admin and other web apps. 

Mike: Could you explain that workaround a bit more? I'm not understanding what you wrote. You made sure your account was an admin on all site collections within the web application, and then you were able to set up the site? When I tried this, I still get the error.

Sean


Hi Sean,

  1. Check you are either primary or secondary admin on ALL site collections within the web application.  (Sounds like you may have already done that.)
  2. Goto "General Application Settings", then under Site Directory 2010 Click on "Configure Scan Job" and change the web application to the same one as used in step 1., then click "Cancel".
  3. Goto "General Application Settings", then under Site Directory 2010 Click on "Configure Site Directory Site", you should then be able to configure the SiteDirectory.

The SP 2010 Site Directory application seems to be defaulting to the last web application selected in anything used on the console.

I have NOT managed to get it to work at all if the site uses https:

The author (martinkearn_msft) asked earlier what authentication was being used, I am now getting better acquanted with SP 2010 and I think this may be the stumbling block for our https web application, which I did not set up, but I can see from the console it has its authentication provider set to "Claims Based Authentication", wheras web applications where I can setup the Site Directory has it's authentication provider set to "Windows".  The author asked whether we were using kerboros, the answer is I don't know beacuse I didn't set up the web app.

Mike

May 13, 2011 at 3:47 PM

Ah, yes. I got it. I had forgotten one Site Collection.

This is fine for testing, but won't be acceptable for live deployment. Hopefully we get an update soon.

Thank you,

Sean

Jun 3, 2011 at 10:31 PM
Edited Jun 3, 2011 at 10:33 PM

There seems to be a bug when calling SPSite.AllWebs when the Web application is configuration for claims authentication.

In this case, the "Access Denied" error occurs at line 69 of SiteDirectoryManager.aspx.cs:

    foreach (SPWeb web in site.AllWebs)

I replaced lines 65-81 of that file with the following code:

    //populate the drop down list with all webs in web application
    foreach (SPSite site in this .WebAppSelector.CurrentItem.Sites)
    {
        using (site)
        {
            SPSecurity.RunWithElevatedPrivileges(
                delegate ()
                {
                   
using (SPSite elevatedSite = new SPSite (site.Url))
                    {
                        foreach (SPWeb elevatedWeb in elevatedSite.AllWebs)
                        {
                            ListItem li = new ListItem(
                                elevatedWeb.ServerRelativeUrl,
                                (site.ID.ToString() + elevatedWeb.ID.ToString()));

                            SiteDirectorySite.Items.Add(li);
                        }
                    }
            });
        }
    }

Using SPSecurity.RunWithElevatedPrivileges avoids the "Access Denied" error when the selected Web application is configured for claims authentication. This may not be the preferred method of resolving this issue long term, but it's good enough for me. (To be honest, I just started looking at this CodePlex solution this afternoon after my client pointed it out to me. I'm assuming the SiteDirectorySiteManager page is only available through Central Administration, in which case it should only be accessible by Farm Admins anyway -- hence I see no immediate concerns about running this piece of code with elevated privileges). 

Jun 3, 2011 at 11:17 PM
Edited Jun 3, 2011 at 11:24 PM

It seems this issue is more of a systemic problem, rather than simply a bug with SPSite.AllWebs (which I incorrectly stated before). The fundamental problem appears to be the fact that the Central Administration Web app is secured using Window Auth and any subsequent attempt to utilize a different Web app that is configured with claims auth results in nasty "Access Denied" errors.

After making the change I described in my previous comment, I discovered that I had to make a similar change in the OKButton_OnClick event handler in SiteDirectorySiteManager.aspx.cs:

SPSecurity.RunWithElevatedPrivileges(
    delegate()
    {
        using (SPSite selectedSite = new SPSite (selectedSiteGuid))
        {
            using (SPWeb selectedWeb = selectedSite.OpenWeb(selectedWebGuid))
            {
                selectedWeb.Features.Add(
GlobalConstants.SiteListingsFeatureID, true);
                globalSettings.SiteDirectorySiteGuid = selectedSite.ID;
                globalSettings.SiteDirectoryWebGuid = selectedWeb.ID;
                globalSettings.SiteDirectoryURL = selectedWeb.Url;
                globalSettings.Update();
            }
        }
    });

This allowed me to successfully configure the site directory on a blank site collection in my Web application (http://foobar-local/sites/Site-Directory). However, I then discovered that you encounter subsequent "Access Denied" errors when attempting to navigate back to SiteDirectorySiteManager.aspx (due to the call to globalMethods.DoesSiteExist(globalSettings.SiteDirectoryURL)). While it seems somewhat reasonable to elevate small portions of code in SiteDirectorySiteManager.aspx, I can't say the same for the GlobalMethods class -- it just doesn't feel right in my gut.

In other words, it looks like it will take some significant refactoring in order to implement the "RunWithElevatedPrivileges" hack throughout SiteDirectorySiteManager.aspx. Of course, a preferable alternative would be to find a better solution to the fundamental problem of configuring a claims-auth Web app from code running inside a Windows-auth Web app (i.e. Central Administration).

Jun 6, 2011 at 2:49 PM

Hi The above code changes make things a lot better.

Site Directory is not configured.

I can now select a blank site in an https: secured web app, when I click Ok i get no error(s).

If I navaigate back to set up the site directory I get the old Access Denied.

If I re-try I get to the same state as if the site directory is not configured.

Can anyone give me a clue as to which extra part of the code may need elevating.

Jun 7, 2011 at 9:47 AM

Hi All,

Having access to a Test Machine I can afford to experiment.

I put the RunWithElevatedPrivileges wrapper in DoesSiteExist and three other methods in GlobalMethods.cs on the basis that The console is running elevated (as already mentioned) and the scan jobs are also run elevated (the "Modified By" column of the list’s data says “System Account”) so I see no risk in adding these “fixes”.

So to summarise I have the following routines running elevated sections (new ones highlighted in blue) :-

SiteDirectoryManager.aspx.cs

  • OnLoad(...)
  • OKButton_OnClick(...)
  • WebAppSelector_OnContextChange(...)

GlobalMethods.cs

  • GetOrCreateGlobalSolutionSettings(...)
  • ResetGlobalSolutionSettings(...)
  • GetOrCreateDeleteListingJobSettings(...)
  • DoesSiteExist(...)

This allows me to get my Site Directory running on a secured site using https

Thanks jjameson for the pointer.

Aug 5, 2011 at 9:53 AM

Folks, Just FYI - I'll ensure that these additions are included in the next version.

Thanks for your input.

Regards

Oct 7, 2011 at 10:19 PM

I've downloaded the latest update and noticed that this has not been implemented?