Strange Sharepoint 403 error - sharepoint

I've installed a Sharepoint site for my team. Everything work fine. But suddenly, I've found that I can not edit the quicklaunch menu: every time I click on Add Item or edit an Item, I get a 403 error.
I've logged with administrator account. I've tried using different browsers such as chrome, firefox, but no hope. The same errors occur when I access Advanced permissions under User and Permission.
Clicking to edit permissions for any group in the list will also cause a 403 error. I think that I may have done some wrong setting with permissions, but I can not figure out what I have done, as I'm pretty new with Sharepoint.
Can you guys tell me how to troubleshoot this problem?
Regards,

You can configure diagnostic logging settings to show why SharePoint gave you a 403 error in the SharePoint Trace Log file.
In central Admin:
On the top navigation bar, click Operations.
On the Event Throttling section, in the Select a category menu, select General
In the Least critical event to report to the event log menu, select Warning
In the Least critical event to report to the trace log menu, select Verbose
Click OK
Go to the Path specified for the Trace Log and reproduce the error. Then open up the last modified sharepoint log file and search for "Denied" (searching up from the bottom of the file). You should see the cause of the 403 error in the log file.

Log in with the site collection administrator account. You most likely removed your own administrative rights from the site (I still don't know why SP will let you do this).
Once you are in, give your normal network account back its administrative permissions.
The site collection administrator account has godlike permissions within its site collection and can override all configured permissions on all securable objects in its domain.

USE THESE CAREFULLY
You probably have a incorrect setup in the service accounts making your server block some internal requests. Try to disabled the Loopback Check:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\
Create a DWORD named 'DisableLoopbackCheck' with a '1' value.
Also make sure your Application Pool (IIS Manager) is running under an actual never-expires user account not the System Account.

Please do not turn off the LoopbackCheck. Turning it off will fix the issue but it also opens you up to a reflection attack which even script kiddies have the ability to do. Instead please use the BackConnection Host file instead.
Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Add a Multistring value named BackConnectionHostName
In this type in the name of your host names. Example: StackOverflow.com
Type each of the names you use to call SharePoint one on each line.
What we are doing here is letting the server know to respond to itself if called by something other than its host name.

Check your ntfs permissions on c:\program files\common files\microsoft shared\web server extentions\12\template\layouts\user.aspx

Related

IIS 8.5 is not serving JS, CSS, and Image files (static content)

The problem
We're running IIS on Windows 8.1 with Update. We're at the Orchard CMS first time setup screen, and IIS is giving 401s for all static content. We have read the following to no avail:
IIS 7.5 no images css js showing
IIS 7.5 no images css js showing
The official Orchard deployment documentation
Based on those, this is what I have tried that doesn't work.
Turn on the IIS feature to Serve Static Content.
Give IIS_IUSRS permission to Read, write & execute.
Give the site's application pool permission to Read, write & execute.
What does work though is the nuclear option: to give Everyone the Read permission (unless we want to proceed with the Orchard setup; then we need to give Everyone even more permissions.) That leads me to believe that I must give permission to some principle with less scope than Everyone but more scope than both IIS_IUSRS and the application pool combined.
Who/what is that principle?
Pictures to show the problem
We receive a 401 on ..\Themes\SafeMode\Styles\site.css
The task manager confirms that the site is running as the orchard user.
The security properties of the ..\Themes\SafeMode\Styles\ directory gives Read permission to orchard.
Why does it only work when we give Read permission to Everyone?
I had a similar problem. Under authentication, I right clicked "Anonymous Authentication" and clicked "Edit". That shows a dialog giving you the ability to set the identity of the anonymous user. I set it to "Application pool identity" and that fixed the problem for me.
.
This may not be the most secure configuration though, but I'm on a dev server so I don't care.
Try turn on the Static Content and Directory Browsing features under Internet Information Services->World Wide Web Services->Common HTTP Features node.
In my case I had to set Read permission for IUSR user for the web site folder.
So, what I had to do to fix this problem was the following:
(and please understand, that this is not ASP or PHP script related, the server wouldn't even show basic simple .html files, yet would serve out PHP results all day long!)
Two fold…
Had to set the application pool for each site, under advanced settings, to use LocalSystem for it’s process
Under site, advanced settings, security, add the IUSR account to have read & list contents access, for the site… :-)
See any problems with doing that?
'cuz it's working....
Updating windows feature for WWW services/Common Http Features/static content by selecting Static Content checkbox fixed my IIS not service static content issue.
Open IIS -> go to advanced settings of selected website and open Physical Path Credentials -> Select specific user and enter your local user credentials. Open below screenshot for further visualising the things:
IIS Settings

HTTP Error 403.14

I'm setting up an MVC site on a new live server. On other non-live servers it worked but on live I get this error
HTTP Error 403.14 - Forbidden
The Web server is configured to not list the contents of this directory.
I have installed MVC 3 and MVC 4 but I still get this error. I restarted the site in IIS and restarted the server but nothing is working. Is there something obvious I'm missing?
I am using IIS7.
You may need to add the correct permissions for that folder.
Right click on the folder in windows explorer and click on Properties.
Go to the Security tab and click "Edit".
Then click "Add".
Make sure the Location is your current computer.
In the object names textbox type in "IIS AppPool\MyApplicationPoolName", where MyApplicationPoolName is the name of the application pool in IIS.
Click OK. In the permissions window make sure the new user is selected and tick "Modify", or whatever permissions you require. Click OK and close the properties window.
Hope this helps - be sure you don't grant more permissions than you actually need in a live environment, but as a rule modify is appropriate for a web application.

HTTP 403 Forbidden : This website requires you to log in

Using asp .net MVC 4.0 , razor , VS2010 , IIS5.2 , windows Server 2003
I have built an application which i want to publish in IIS. what i did is listed below:
Cleaned then built the solution.
right click on project file and clicked PUBLISH.
publish method : File System
Target Location : C:\Inetpub\wwwroot\testing
then publish.
Then i went to IIS and got my site in Default web sites. happy :). Then i did:
right clicked on testing(my app) and open properties.
In the tabdirectory everything goes fine.
in asp.nettab, i set asp .net version 4.0.30319
here is a little confusion, I set home/index as my default content page in documentstab
then I right click testing and clicked browse. And it shows :
Most likely causes:
This website requires you to log in.
This error(HTTP 403 Forbidden) means that this program was able to connect to
the website, but it does not have permission to view the webpage.
a short summury what i got as error message. This is my fist mvc application and first hosting. What is my fault here? what should i do now?
I had the similar issue. Please try the following:
A. Suggestion below from Microsoft Technet helped me:
The solution is to ensure that the Authenticated Users or \Users group (which usually contains DOMAIN\Users group) has Read & Execute, List Folder Contents and Read permissions on the /BIN folder below C:\inetpub\wwwroot\wss\VirtualDirectories{Sitename80}. Follow the steps listed below to grant the required permissions:
Open Windows Explorer and navigate to the /bin directory of
your web application
Right-click on the folder and click on Properties
Go to Security tab and click on Edit
Click on Add and add the local server group Authenticated
Users or < SERVER NAME >\Users (this usually contains
DOMAIN\Users group).
Select the Read & Execute, List Folder Contents and Read
permissions (if you are planning to add Everyone to the /bin folder,
grant Read permissions only)
Click OK to apply the new settings
NOTE: you may need to to it after every Publish, as permissions somehow may get reset.
B. In VS - set the default page for your website, or try navigating to specific page as opposed to simply opening the website with only the site name.
I know it sounds dumb, but that also was the problem for me
after publishing your webiste to IIS, navigate to http://myServer/mySite/somePage instead of http://myServer/MySite

Access rights for users of "Members" group?

I have a test user account, who is in the group "Members" with the default permission level of "Contribute". I created two custom aspx pages in Visual Studio, that are stored in the _layouts directory. How is it possible that this user account can view one of those pages, but not the other? One page has a single button on it and the other has a gridview, displaying list items. He can view the page with the gridview, but not the page with a single button. Anyone has an idea why?
Oh, and he is also prohibited from viewing a custom web-part written in Visual Studio, for some reason.
Ok based on your comments it sounds like you are probably accessing either the Group itself and the current user doesn't have access to view the members of the group. Note it may also be something else in your code behind that the current user doesn't have permission to do. Typically the access denied page happens without an exception so you'll have to look at the SharePoint ULS logs for more information on the error. (Technically it aborts the normal page rendering life cycle and redirects the user to the Access Denied page.)
ULS logs are found in the 12 hive under the LOGS subdirectory. I would suggest using the ULS Viewer instead of trying to visually parse through the logs with NotePad (there's a lot there).

Office documents prompt for login in anonymous SharePoint site

I have a MOSS 07 site that is configured for anonymous access. There is a document library within this site that also has anonymous access enabled. When an anonymous user clicks on a PDF file in this library, he or she can read or download it with no problem. When a user clicks on an Office document, he or she is prompted with a login box. The user can cancel out of this box without entering a log in, and will be taken to the document.
This happens in IE but not FireFox.
I see some references to this question on the web but no clear solutions:
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.sharepoint.windowsservices.development&tid=5452e093-a0d7-45c5-8ed0-96551e854cec&cat=en_US_CC8402B4-DC5E-652D-7DB2-0119AFB7C906&lang=en&cr=US&sloc=&p=1
http://www.sharepointu.com/forums/t/5779.aspx
http://www.eggheadcafe.com/software/aspnet/30817418/anonymous-users-getting-p.aspx
To disable login prompt opening office documents from SharePoint 2010 do the following settings in web.config
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true">
<!-- here's where the magic happens -->
<verbs allowUnlisted="true">
<add verb="OPTIONS" allowed="false" />
<add verb="PROPFIND" allowed="false" />
</verbs>
</requestFiltering>
</security>
</system.webServer>
If Sharepoint Shared Workspace is enabled in MS Word this may prompt users with a Windows login if users do not have permissions to access or create a Shared Workspace. Do the followoing to turn this off:
Open MS Word
Go to Tools/Options
Click General Tab
Click Service Options
Click Shared Workspace
Uncheck box that says “The document is part of a Workspace or SharePoint Site.”
Click OK
Click OK
Try to hit a MS Word document from the SharePoint site.
If this resolves issue repeat steps with every MS Office program to eliminate the prompt. (Excel, PowerPoint, Visio, ect)
http://office.microsoft.com/en-us/word/HP010414641033.aspx
Unfortuantly the only work around I've found breaks some functionality for logged in users (can't upload multiple files, connect to outlook ect..)
If that is acceptable, or you want to try it and see:
In central admin > application management > application security > authentication providers select your web app and select your provider (likely "default").
Select No for client integration and save the settings.
Open your web config, find the line <add verb="OPTIONS,PROPFIND,PUT,LOCK,UNLOCK..... and remove the verb OPTIONS.
You should no longer be asked in ie for credentials. To reverse this simply undo both changes.
If you can click cancel and it comes up the problem is...
AuthForwardServerList
http://support.microsoft.com/kb/943280
Office doesn't know the site is trusted/local so it doesn't fwd your credentials and prompts you with an opportunity to provide them. It's a feature....
If you list your site in the proper registry key it will forward your credentials which are not needed but you won't get prompted.
If you have a url rewriting module or urlscan, configure the software to send http 403 to http OPTIONS requests.
In the Sharepoint Server 2010, The solution method is a little bit changing because the new generation Sharepoint can not hold verbs in web.config. Therfore, you must change the method. First of all, you open IIS 7.0 and choose your application site. You can see many items at the middle of the screen. You choose and double click Request Filters. In the request filtres, you can see "Verbs". You can add OPTIONS and PROPFIND verbs to a deny mode. And finally test your site. Sometimes, Sharepoint needs to close Client Integration Mode of your site. If need, you can close Client Integration Mode in Central Administration.
Possible cause and resolution:
http://support.microsoft.com/kb/943280
"You are prompted to enter your credentials when you access an FQDN site from a computer that is running Windows Vista or Windows 7 and has no proxy configured"
"For example, when you open a Microsoft Office file from a Microsoft Office SharePoint site by using 2007 Microsoft Office on a Windows Vista-based client computer that has no proxy configured, you are prompted for authentication."
My guess is that the Office client is loading the underlying document template from another location where anonymous access is enabled. This also explains why you can still open the document as the Office client can also work without loading the template the document was originally created from. To see the template URL in Word 2007, enable the Developer Ribbon from Word options and click the Document Template button on the ribbon.
That doesn't seem to be it. Once of the documents in question is an Excel file, which would not use the .doc template. Also, in the Document Template dialog, it doesn't give me a url to the SharePoint template file if I create a new Word document based on it. It just says the template is "Normal." I also tried disabling the template at the document library level and it doesn't change the password situation.
When opening an Office document in IE, an ActiveX component is used to call the client application, and prompt it to open the document. In other browsers, the download is a standard hyperlink, handled by the browser.
Does this happen in search results and in standard linked columns in document libraries as well?
Using a tool like Fiddler (as referenced/suggested in your first link reference, see http://www.fiddlertool.com/fiddler/ for more info) is the only efficient way of determining the root cause of this type of issue I'm aware of. Whatever is causing this will be happening over HTTP. A debugging proxy like Fiddler will show you exactly which URL/resource is causing the request for authentication.
On a related note, are you running a recent build of the platform? It might be wise to check to make sure this issue hasn't already been addressed by MS e.g. in a hotfix. The best list of updates I'm aware of is here: http://www.harbar.net/articles/postsp1.aspx
Check this : Remove Login box when anonymous users download office document from SharePoint Site
http://www.theblackknightsings.com/RemoveLoginBoxWhenAnonymousUsersDownloadOfficeDocumentFromSharePointSite.aspx
When developing Extranet/Internet site in SharePoint you often want to allow anonymous access and this works fairly well.
But there is one are where the out of the box experience fails regarding anonymous access and that is when you allow the users to download Microsoft Office documents. In that case IE/Office pops up a couple of Login dialogs, if the user cancels out of these the document opens as expected, but you really don't want the user to have to cancel a couple of dialogs to open your documents
The problem is that office tries to be intelligent and issues a Microsoft Office Protocol Discovery request to see how much the user is allowed to do, but SharePoint responds with access denied until the users logs in.
The solution I've found is to implement a HttpModule which rejects the Microsoft Office Protocol Discovery request if the user isn't logged in and this gets rid of the Login boxes
I'm guessing that you use Windows Vista. We had this problem on Vista but not on XP.
From Microsoft: In Windows Vista, Internet Explorer uses the Web Client service when you use Internet Explorer to access a WebDAV resource. The Web Client Service uses Windows HTTP Services (WinHTTP) to perform the network I/O to the remote host. WinHTTP sends user credentials only in response to requests that occur on a local intranet site. However, WinHTTP does not check the security zone settings in Internet Explorer to determine whether a Web site is in a zone that lets credentials be sent automatically.
If no proxy is configured, WinHTTP sends credentials only to local intranet sites.
Note If the URL contains no period in the server’s name, such as in the following example, the server is assumed to be on a local intranet site:
http://sharepoint/davshare
If the URL contains periods, the server is assumed to be on the Internet. The periods indicate that you use an FQDN address. Therefore, no credentials are automatically sent to this server unless a proxy is configured and unless this server is indicated for proxy bypass.
This is a known issue that has not quite been completely fixed yet. There is a MSDN blog about it here: http://blogs.msdn.com/sharepoint/archive/2007/10/19/known-issue-office-2007-on-windows-vista-prompts-for-user-credentials-when-opening-documents-in-a-sharepoint-2007-site.aspx
There is an interesting workaround posted here: http://grounding.co.za/blogs/neil/archive/2008/11/10/workaround-sharepoint-keeps-prompting-for-login-when-creating-office-2007-documents-on-vista.aspx
Ultimately there is a patch that has been included with Vista SP1 but it also requires a registry edit. We just recently got this to work using the following steps on a Windows Vista SP2 client:
Open regedit. Navigate to the following subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
Create a new Multi-String value called AuthForwardServerList and give it a value of (for example):
https://.Contoso.com
http://.dns.live.com
*.microsoft.com
https://172.169.4.6
Then restart the WebClient service.
We were able to get this working by changing IE settings.
We have the site URL in Trusted Sites.
Under Custom Settings set User Authentication to: Automatic logon with current user name and password
I found a solution. First of all, you open the web application config file under the inetpub. Then you find the add verbs section. In this section, many verbs were added in the installation time. Delete Options and Profind verbs and save config file. Finally test the problem and see it. The problem is finished.
I've found the following workaround:
http://www.objectsharp.com/cs/blogs/max/archive/2008/04/21/sharepoint-public-facing-website-and-microsoft-office-documents.aspx
To keep it simple:
Disable client integration
Remove the OPTIONS verb from the registration line in the web.config file for the site

Resources