UPDATE
I can now perform succesful UI impersonation. This was an issue with the code I was using and after viewing Jay Nathan's article I have reverted to his code and all is working great.
In response to a comment this is the code I am using to create a new site collection:
Dim newSite As SPSite = webApp.Sites.Add( _
txtWebApp.Text & "/cg/" & strURL, txtName.Text, txtDesc.Text, 1033, "SITEDEF#0", _
"DOMAIN\ACCOUNT", "NAME", "EMAIL", _
"DOMAIN\ACCOUNT", "NAME", "EMAIL")
and yes "SITEDEF#0" is a perfectly valid site defintion.
Hopefully I have overcome this issue by using an Application Page which is available as an element on the Site Actions menu (to site admins only). Using impersonation I can succesfully instigate this process. There are some additional issues which I have highlighted in another question.
ORIGINAL QUESTION
I have a need to allow non farm administrators to be able to create site collections using a very specific site definition. These people will not have access to central admin and so require a custom solution to allow the creation of these. I have tried several solutions, but want some consensus on a recommended approach.
Custom Web Service - I have written a custom web service to perform this task however this caused major headaches and even though the web service was running in an app pool using the same identity as the sharepoint app pool I could not get this to work. Also had form digest issues in trying to perform this v ia a web service.
Web Part/Application Page - No form digest issues here as we are in the SharePoint context, however I have tried using RunWithElevatedPrivileges but I still get an access denied when calling SPWebbApplication.Sites.Add(), even though all SPSite and SPWeb pbjects are being instantiated inside the elevated code block. I have tried direct impersonation at the UI level and I get an UnhandledException saying that impersonation has failed.
Application Wrapper Around stsadm - I have not attempted this yet as I am concerned about the viability of this approach, surely there is a cleaner way than this?
Some guidance on this would be useful as I cannot find much out there on this.
Thanks
I'd go with option number 1. It's probably an authorization issue. How are you accessing SharePoint? with the SDK or trough its web services?
I'd go for number 2. That code should work, maybe the impersonation code is not correct? You can't use SPContext like you normally would for instance.
Also, you are elevating to the identity of the application pool of your SharePoint site. Does this account have sufficient rights to create Site Collections?
You can check in Central Administration > Application Management > Policy for Web Application.
Related
I currently have a web config file in a web service that is using the following code snippet so that it can access resources on Sharepoint
<identity impersonate="true" userName="[domain admin]" password="[password]"/>
Clearly this situation is not a good idea and we are currently replacing this with the correct way of doing things. However, in the mean time we are creating a new domain user that is NOT the domain admin and using that as a stop gap. The domain admin was used as people were too lazy to determine the right security levels required and a domain admin will be guaranteed access to every resource.
My question is: What is the minimum level of security that this domain user requires in order to continue accessing the Sharepoint Web Service? What sort of things should I be thinking about?
What web service are you talking about exactly? SharePoint web services are permissions aware, just like any other module, so it is different if you want to say read items or create a site. You need to know first what you are trying to accomplish and then give the user the exact permissions to do that
Here's the scenario:
We have an external SharePoint instance with anonymous access turned on. We want the document libraries open to the public. We do not want custom lists open. That was simple enough to configure.
Now we want to use those lists to create an attractive external ASP.Net web application. This web site will need anonymous enabled as well.
The problem is we need to access those lists from the web application without opening them to anonymous access.
We want to use the API (not web services) since this will be hosted on the same boxes.
So far we have been unable to create an SPUser with the appropriate access to open the lists.
SPContext is empty.
Doing this fails as well:
SPSite temp = new SPSite(URL);
SPUserToken token = temp.SystemAccount.UserToken;
SPSite site = new SPSite(URL, token); ...do stuff as the user.
RunWithElevatedPrivileges also fails.
Please help!
Any chance you are using SharePoint 2010? They have more options available to access from other applications. If not 2010, you are going to have to use a web service of some kind, either the OTB ones or your own Web Service that encapsulates your logic since the SP OM will not run on a non SharePoint box.
Independent of that, you could try getting the SPToken from the Application pool. Essentially
SPUserToken sysToken = SPContext.Current.Site.SystemAccount.UserToken;
using(var systemSite = new SPSite(SPContext.Current.Site.ID, sysToken))
Daniel Larson is a big proponent of this approach over using RunWithElevatedPriveleges. Check out his blog post on the matter.
I'm trying to set up surveys for a public facing MOSS site that allows anonymous access. I'm willing to live with the restrictions and have followed the instructions on the blog teuntostring- using-surveys-on-anonymous-access.htm (I can't add the link here as I'm a new user) to the letter (I think). However, I end up with a login prompt every time I try to access the survey.
Note that this is a publishing portal. Can anyone help?
Anonymous people cannot contribute, in any form.
There are a couple of options as work around.
1) Use an infopath web form and have it submitted as a web service. This does require that you write a web service to handle it, there are multiple examples of this around.
2) fake the web service with javascript and hard code account information.
3) have an account that anonymous users automaticly log in as, requires a handler.
see
http://blogs.devhorizon.com/reza/?p=551
http://www.elumenotion.com/Blog/Lists/Posts/Post.aspx?ID=11
http://wssguestaccount.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12313
We have a SharePoint application where we want the user to be able to modify the web.config by activating a feature. The application is extended, so we have an AD based web application and another that uses Forms Based authentication (FBA), with the FBA application being the "main" user application.
We use the SPWebConfigModification class (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx) to write to the web.config for settings we need for the activated feature.
This works great on the AD based side of things. However, when we try and run this on the FBA based web app, we get an error because the site collection administrator for the FBA site, does not have any access to modify the web.config on the server. Given that they are a FBA user, we can not give them rights on the server either.
Has anyone run into this? Does anyone have any work arounds. I assume I could try and have the application to update the web.conifg run via the command line, but I would really like it be done by the user when they activate the feature. I could also try and loosen security rights on the web.config, but that is a bad path to start down.
Thanks!
John
An alternative would be to write a component which does it.
This could be trigged by activating a feature, or updating a webpart.
This would mean you don't need to loosen security, or do it via the command line.
Here's the scenareio:
I have a single site collection, with the publishing infrastucture feature activated. Seveal levels below this I have a publishing site with the publishing features turned on. I also have unique permissions for this site.
The problem is that no one except site collection administrators can "Create Page". I have given the individuals everything including full control, and they still can not create pages. They can edit pages, but not create.
Am I doing something wrong? What is the proper way to set up the taxonomy of a site? I am trying to create a hierarcy to match my organization and mostly am using unique permissions on each site/subsite. This is working ok, until i needed a publishing site, but I don't want him to be a site collection admin. I would appreciate any help or ideas with how to make the publishing site work as I have it, or guide me on the proper way to lay out the site.
The fact that you are using Publishing features shouldn't have an effect on permissions. Publishing (for the most part) really has more of an effect on how edits are handled - i.e. immediately deployed or checked in and published at a later point. That's oversimplifying it - but back to your question.
Most likely - what is happening is that you have not given the user permission to the library where the template is that they need access to in order to create the page. I'm 99% sure that is what is happening here. Makes sense - they have the rights to the site - and permissions to edit the pages that exist - but creating a page requires them to access a new file - in a different library. If they don't have permissions to that template library - you get the access denied error.
When your user tries to create a page, they get an access denied error page correct? Copy the URL of that page, and examine it closely. It should reveal the location of the template folder they are trying to access but don't have permissions for. Read-only access to that template library should get your user the access they need.
One other recommendation - check out the access checker web part in Codeplex. http://accesschecker.codeplex.com/. This web part is loaded as a solution and allows you to display a hierarchical list of the sites that a specific user has permissions to. VERY helpful in confirming that you have given the permissions you thought you had.
Finally - in terms of permissions best practices - I think you are doing fine. You've gotten a little frustrated because you took a different path on a site (i.e. publishing) and it's behaving differently. But nothing is wrong. I've been there:) You really have two options w/ SP permissions - SP based groups (visitors, members, owners etc) or pulling in AD groups. Either way, you'll be making the same decision regarding unique or inherited permissions. You either use the same permissions as the parent site - or use unique permissions. HTH