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.
Related
I have created a test SharePoint server to be as close to our production server as possible. Production SharePoint databases were backed up and restored to our test server. The three main web.configs (Central Admin, main site, Security Token Service Application) were modified to include our custom app settings.
The site comes up fine, logging in using both AD and our custom FBA membership provider works as well.
Certain pages are visible in the Site Libraries through View All Site Content and using SharePoint Designer but SharePoint says that the page(s) are not found if you try to view them or check them in. Not all pages are not available. If I delete a bad page and replace it with a copy from our production application, it displays fine.
I've already found and tried possible solutions such as restarting the Search Query and Site Settings Service and checking the Alternate Access Mapping. I also found a possible solution that has you go to Component Services and modify security relative to an OSearch14 property. I was not able to modify this since right clicking on the property did not pop up any menu options. I will continue to look into this.
Any Ideas? I appreciate any help.
Thanks.
I have somewhat of an odd question (for me, at least).
We have some private information a department would like to place on our SharePoint farm. The problem is, this is very sensitive information, and law demands that we have a 'two-stage' login process to secure the data.
Currently, it is housed using a system that:
A) you have to login to our network (windows logon screen)
B) you have to login to the application.
Our SharePoint farm has integrated authentication enabled. Meaning, once you login to your computer in the morning, you never have to login to sharepoint as it already knows your credentials.
This is a problem for us. Can we enable some sort of custom Sharepoint login?
Will this require a new web app for the site? A new site collection only perhaps?
Thanks,
~~Kolten
What you are looking for is called forms based authentication. Sharepoint 2010 uses claims based authentication and one of the providers you can configure is forms based. Meaning they provide a user name and password.
Here is a tutorial with the steps to do, it is a relatively straight forward process. just follow all the steps.
http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx
If you move you site out of Intranet zone, then IE will automatically ask for credential everytime.
See this:
http://support.microsoft.com/kb/258063
I have enabled anonymous users on the farm and on the entire site.
I also have Windows Authentication turned on.
Whenever an anonymous user attempts to view the site, they are prompted to log in.
And they get prompted to login on every single page they view.
I would like to allow users to log in via Windows Authentication, (perhaps through a special page), but anonymous users should not get prompted to put in their password ever.
Does that mean I need to switch to forms based authentication for the entire site, or is there an option in 2010 to somehow get Windows Authentication and allowing anonymous users to live harmoniously.
It could be because some of the file is not published. For ex, if master page, CSS stylesheet or any image is unpublished, it will prompt the user for login.
Make sure everything is published and it will work.
You need to see if it is anything on this path http://server/_catalogs/masterpage/Forms/AllItems.aspx
that it is not published.
You must publish everything
May be you missed some of the configuration steps .So i wish if you take a look to the following article
SP2010 Branding Tip #9 – Turn on Anonymous Access
Regards
I assume that you are using the Publishing Site Template for the public site and hence the default.aspx (the welcome page of all the subsites) is not published so you would need to start the approval workflow publish the pages and any other assets (master page, css, images etc)
You need to do some prepwork to set the site up using two web applications, both with different authentication methods. You can't run SharePoint effectively for Windows users and anonymous (or Forms based authentication) at the same time.
Essentialy:
Create your SharePoint site for internal users using Windows Authentication
Extend the site to a new site (using the same content database) but using anonymous or forms based authentication (whichever makes sense for you)
A MSDN article can be found here on this:
http://msdn.microsoft.com/en-us/library/ff648385.aspx
You can also read Andrew Connell's blog about this (he talks about Forms based authentication but you can do the same with anonymous access)
http://www.andrewconnell.com/blog/articles/HowToConfigPublishingSiteWithDualAuthProvidersAndAnonAccess.aspx
Basically you want dual authentication, Windows for one set of users and anonymous or FBA for another (and each access the site using a different URL)
Hope that helps.
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
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.