401 Unauthorized error web api mvc windows authentication

Question

I am getting 401 unauthorized error . My web service is written in mvc . in IIS configured to use windows authentication. Below is screen shot of fiddler

When I hit URL from browser it gives me popup window to enter user name and password. How can I avoid popup window?

I am calling this web api from another window service.

Suboceanic

Answer 1

I added below lines in web config to fix the issue and it worked.

   <security>
        <authorization>
            <add accessType="Allow" users="*" />
        </authorization>
    </security>

Suboceanic

Unsecuring your website to fix a localised issue isn't the best idea, shirley? – Bloodhound

where we should add this lines? – Acton

@Ashkan, you shouldn't ideally but it can be added to the <system.webServer> section of the Web.config – Bonesetter

@Bonesetter tnx. I found my problem in folder permission in windows. I set IUser to my folder and problem solved. – Acton

This change causes all users to be authorized successfully; therefore disabling any security you are trying to implement. If this solves your issue, than you should be using 'Anonymous Authentication' instead of 'Windows Authentication'. – Unitarianism

Answer 2

I suspect that the two web services may be hosted on the same server. In this case, the problem may be caused by the loopback check. In order to test, try referencing the service without using the fully qualified domain name and see if it works. If it does, use the following steps to specify which host names are on the local computer.

Method 1: Specify host names (Preferred method if NTLM authentication is desired) (https://support.microsoft.com/en-us/help/926642/)

To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

1. Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base: 281308 Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
2. Click Start, click Run, type regedit, and then click OK.
3. In Registry Editor, locate and then click the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
4. Right-click MSV1_0, point to New, and then click Multi-String Value.
5. Type BackConnectionHostNames, and then press ENTER.
6. Right-click BackConnectionHostNames, and then click Modify.
7. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
8. Quit Registry Editor, and then restart the IISAdmin service.

https://learn.microsoft.com/en-gb/archive/blogs/sharepoint_foxhole/disableloopbackcheck-lets-do-it-the-right-way

**Edited to be in the form of an answer and include detailed steps from referenced links

Ranite

Answer 3

If you are using WebClient you need to set the Credientials. How are you calling the web api from the windows service?

Graybeard

Answer 4

You can specify the username and password as part of the URL:

http://username:[email protected]/foo/bar/baz

Note: Just because you can doesn't mean you should. While this can be a temporary solution to test things, I would not suggest doing this in production. And in the old days, this is how we did it. But as @DiskJunky points out, "URLs are easily visible to pretty much anything/anyone" which includes your browser history, server logs, and perhaps worse.

Concert

I'd imagine it's because putting the password into the URL is a security no-no. URLs are easily visible to pretty much anything/anyone and putting the password in there is...unwise to say the least. – Bonesetter

Answer 5

My 2 cents: I faced a scenario where we were baffled by an HTTP 401 when requesting an image when the web application was deployed. We use WiX as our packaging and install solution. In this specific case, the image wasn't being packaged by the installer and hence the path did nor exist on the deployed instance.

One may wonder why this threw a 401 when a 404 (not found) would have been expected - my understanding is that since our path was not directly under the root but something like root/content/images/image.png, and I made an anonymous request, I got a 401 (unauthorized) as I did not have the access to browse the directory. I confirmed this by adding an Authorization header to my request and then as expected I got a 404.

Giulietta