I'm trying to run one of my web app APIs but when prompted for user and password, it responded with 401 access denied. I've tried changing from NTLM to Kerberos. It still won't work. I'm new to SharePoint.
This is how I call my API :
var json = $.ajax({
url: (serviceType == "wcf" ? wcfServicesUrl : servicesApi) + wcfServiceUri,
type: type,
data: data,
crossDomain: true,
contentType: "application/json",
dataType: "json",
xhrFields: {
withCredentials: true
}
)};
You need to adjust the authentication settings in IIS for your Web API application.
Depending on what you are trying to do, you may need one or more of these options enabled.
Your app pool identity also plays a role. Make sure they user is properly authorized to access your content / data / etc.
Update: set Windows Authentication as Enabled, make sure all others are disabled. Do not use Kerberos. Add URL for your web app to Trusted Sites in your browser.
i have recently came across production issue where my PRODUCTION API server suddenly starts giving 401 unauthorized error , I searched a lot on internet but fruitless than I took support from Microsoft as this application was running fine , suddenly the error occurred , Microsoft just took a look on which dot net frame work the application is using mine was 4.0 , so they advised to go to C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
when an application is hosted on IIS , it compiles its dlls and other files once in this particular folder ,if it gets lock or corrupt the application will start giving 401 unauthorized error
and delete the temp files and restarted IIS and Voala it start working .
Please mark it as a answer if you are comfortable
401 can also be NTFS permissions, take a look here:
Try below solution, it worked in my case. First open IIS and click your site. And then:
Right click "Authentication"
Click "Open Feature"
Select "Anonymous Authentication"
Select "Edit" From "Actions" on the right
Select "Application Pool Identity"
Click "Ok"
Related
I know this question has asked before many times. I've tried every one but no luck,
I my situation,
Website url: https://mywebsite.com/qa
redirect url: https://mywebsite.com/qa/login/facebook/callback
I have added my domain to app domain, redirect url to valid oAuth redirect url. But same error.
I even created a new app.
However facebook authentication is working fine with https://mywebsite.com/ domain. It's is a different app and a website.
The issue happens only with the site in the sub folder.
Any help ?
Thank you.
EDIT
Screenshot
Can you check if "Valid OAuth Redirect URIs" in Facebook app "Facebook login" setting is properly defined like shown in screenshot attached ?
Also have you checked if your app has strict mode enabled ?
This error occurs if your OAuth setting is not correct.
I would suggest to check all settings of your app thoroughly.
I've been away from coding for a few years so excuse the simple nature of this question. I've downloaded the Houndify web sdk and followed instructions to get it running on my local web server (localhost). When running it I get the authentication error "signed token rejected". I've updated the config.json and index.html with my client ID and Key. Any ideas?
E W
Can you check:
if you have activated your account by clicking the link in the email
test the request from the API console from the Client dashboard page
I have had the same error and realized that my account was not activated.
I have installed the Google Drive Realtime API sample files on my web server, following these instructions, including generating a client_id in the Cloud Console and inserting it into the index.html file.
When I visit that page and click the button to authorize the app, it pops up with a new window and shows:
Error: invalid_client
no registered origin
The Request Details are:
openid_connect_request=true
cookie_policy_enforce=false
scope=https://www.googleapis.com/auth/drive.install https://www.googleapis.com/auth/drive.file https://www.googleapis.com/auth/plus.me
response_type=token
access_type=online
redirect_uri=postmessage
proxy=oauth2relay865404532
origin=http://mywebsite.com
state=264939258|0.165356673
display=page
client_id=1077585001321.apps.googleusercontent.com
authuser=0
I can't see any other client_id that I should be using in the Cloud Console. Does anybody know how to overcome this error? Thanks for your help.
In the new Google API Console, configure your OAuth2.0 authorized origins from
Your Project > APIs & auth > Credentials
You might need to add a new Client ID specifically for a web application (I did because the default was for AppEngine)
Create Client ID > Web Application > Authorized Javascript origins
If you are running on a local dev server, just add the exact URL such as :
http://127.0.0.1:9000
UPDATE: I changed accepted answer to Johno Scott instead as he refers to the newer version of the console, whereas mine was only true for the older version.
I solved it. I needed to enter a WEB ORIGIN on the OAuth 2.0 Client ID screen. Specifically, it had to be the exact path/url of the index.html file, otherwise it defaults to the root domain which doesn't work.
This screenshot shows you exactly where it needs to be entered:
I am working on ASP.NET 4.0 MVC3 web application that works in intranet environment. The application makes use of Windows authentication. Its application pool is run by domain user that has spn set on a domain controller. Authentication works using Kerberos (on IE and Firefox after some additional configuration).
Now I want to upload files to sharepoint, but it's important for me to upload the file as the user currently logged in into the application (so the file is created on Sharepoint with his/her credentials).
I have the following code in ResourceExists(Uri uri) function:
'...
Dim identity As System.Security.Principal.WindowsIdentity = HttpContext.User.Identity
Dim impersonationContext = identity.Impersonate()
response = request.GetResponse()
impersonationContext.Undo()
'...
This works when running locally, but when I deploy to the server I get the exception:
System.Net.WebException: The remote server returned an error: (401) Unauthorized.\r\n at WebDav.WebDavClient.ResourceExists(Uri uri)\r\n at Website.Website.WebdavController.Upload(HttpPostedFileBase file, UploadViewModel vm)
I read something about passing on the credentials, that is not possible with NTLM, but I am sure I am using Kerberos (I checked the headers with wireshark and fiddler) and I see the following:
Authorization: Negotiate YIIFpQYGKwYBBQUCoIIFmTCCBZWgJDAiBgkqhkiC9x...
Any ideas why the impersonation does not work when running on the IIS server?
I found the answer here:
http://support.microsoft.com/kb/810572
"Kerberos does not work in a load-balanced architecture and IIS drops back to NTLM authentication. Because you cannot use NTLM for delegation, any applications or services that require delegation do not work. For more information, click the following article number to view the article in the Microsoft"
And that was exactly the case. I tried now with another machine that is not load-balanced and it works.
The only thing that still surprises me is that ImpersonationLevel of the identity is still Impersonate not Delegate...
After setting <identity impersonate="true"/> in your web.config try the following:
using (((WindowsIdentity)User.Identity).Impersonate())
using (var client = new WebClient { Credentials = CredentialCache.DefaultNetworkCredentials })
{
string result = client.DownloadString("http://sharepoint");
}
you need to configure your site correctly in IIS for impersonation to work.
see Configure ASP.NET Impersonation Authentication (IIS 7)
Folks,
I've got an ASP.NET MVC application that I am attempting to secure using the Release Candidate version of ADFS v2.0 (Geneva). I have configured the application as a relying party trust, and I've used Fedutil.exe to modify the application's Web.config so that it has the information about the Geneva server and uses the Geneva server as its claims source.
However, when I try and hit the MVC app, it redirects to Geneva, which then (after warning me about self-signed certs) re-directs me to the MVC app again. After accepting both self-signed cert warnings, the two servers play ping-pong with each other in an infinite redirect loop until finally Geneva spews the following message:
The same client browser session has made '6' requests in the last '1' seconds. There could be a possible bad configuration. Contact your administrator for details.
There are no errors in the event logs on the MVC side or on Geneva except for an event containing the above message. If someone could give me some information on how to try and debug, diagnose, and hopefully fix this problem, I would be eternally grateful.
Again, the Geneva box is the ADFS v2.0 Release Candidate and the ASP.NET MVC site was built using the latest (late '09) version of the Windows Identity Foundation SDK with Web.config modified using FedUtil.exe from the WIF SDK.
So you will all get a kick out of this... I tried this same application from Firefox and ... IT WORKS. I get prompted for my domain credentials, the ADFS v2 server re-directs me ONCE and then I end up on the home page of my application, complete with my account name and personalized greeting.
So now the real issue is this: Why the hell is IE8 getting caught in an infinite redirect loop and Firefox ISN'T ??
After even further testing, I've been able to get this scenario working, out of the box, without modification of any of the default pipeline stuff from ADFS v2 (RC) or from WIF (RTW) on BOTH Safari AND Firefox. IE8 is the ONLY browser to exhibit any problem dealing with this authentication scenario. I've tried everything, including installing and trusting the self-signed certs, adding the sites to my local intranet zone and dropping security to low and even setting first AND third party cookies to always allow.
I had the same issue with ADFS 1.0
And to resolve it, I made sure that the URL had a trailing forward slash "/" that would always work in FireFox as well as IE
eg : https://somedomain.com/Application_2/
Turns out that the host name of the relying party had an underscore in it (khoffman_2). Apparently, the underscore is an illegal DNS character and ONLY IE will reject the information with the underscore in it.
I renamed my machine from khoffman_2 to khoffman2 and the ADFS v2/MVC relying party combination works flawlessly on Firefox, Safari, AND IE.
While this isn't your problem, we have had identical problems to what you described. Our solution was to:
Enabled Basic Authentication in IIS (this solved nothing but was required for the next 2 steps)
Disable Windows Authentication in IIS (this solved the problem for some IE browsers but not all)
Disable Anonymous Access in IIS (this solved the problem for the rest of the IE browsers)
Jaxidian's answer is close.
In my case I only had to:
Windows Authentication -> Disabled
Anonymous Auth -> Enabled
ASP.NET Impersonation -> Disabled
Forms Auth -> Disabled
Windows Auth -> Disabled
This loop can occur when a user is not authorized to access a page.
We had a custom authorization attribute on our MVC controller that checks to see if the user was in a role based on the claims provided if the setting for UseADFS was true in the config files. I thought this setting was set to true and was confounded that I kept getting the adfs loop when accessing the page because I was in the groups that were authorized to access the page.
The key to troubleshooting was to make a web page that displayed my adfs claims without necessarily requiring authentication.
#if (User.Identity.IsAuthenticated)
{
<div>UserName: #User.Identity.Name;</div>
var claimsIdentity = User.Identity as System.Security.Claims.ClaimsIdentity;
<table>
#foreach (var claim in claimsIdentity.Claims)
{
<tr><td>#claim.Type</td><td>#claim.Value</td></tr>
}
</table>
}
I noticed that I was getting logged into ADFS, and my claims were getting set, so ADFS was working. The actual issue was my config file had UserADFS="true" instead of UseADFS="true" which basically caused my custom authorization code to return false on authorization. Therefore, the page kept forwarding me back to adfs to authenticate again.
Anyways, if a user does not have the correct claims to access the page, then this adfs login loop can occur, as well.
Also, if you wrote a custom authorize attribute be sure to check out the following link which describes how to prevent the loop.
Redirect loop with .Net MVC Authorize attribute with ADFS Claims
Custom HandleUnauthorizedRequest handler code for AuthorizeAttribute from that link:
protected override void HandleUnauthorizedRequest System.Web.Mvc.AuthorizationContext filterContext)
{
if (filterContext.HttpContext.Request.IsAuthenticated)
{
//One Strategy:
//filterContext.Result = new System.Web.Mvc.HttpStatusCodeResult((int)System.Net.HttpStatusCode.Forbidden);
//Another Strategy:
filterContext.Result = new RedirectToRouteResult(
new RouteValueDictionary(
new
{
controller = "u",
action = "LoginStatus",
errorMessage = "Error occurred during authorization or you do not have sufficient priviliges to view this page."
})
);
}
else
{
base.HandleUnauthorizedRequest(filterContext);
}
}