IIS CORS Module configuration with Windows Credentials

Charlotte McClellan 20

Hi,

Does anyone have a Windows .Net Core API being accessed via Windows Authentication?

I have not been able to get this to work.

I have an .Net Core API hosted on my Windows 2022 server in IIS with Windows Authentication enabled. We have a on-premise Active Directory 2019 server doing the authentication.

If I go to the API URL in a browser, the Windows authentication window pops up, I enter my credentials, and I get the appropriate JSON data back.

I am now trying to access the API via a JavaScript fetch call from a page in our Intranet that also uses Windows Authentication (same server, different web site, same domain).

The fetch call listed below triggers a CORS preflight options request and response which succeeds.

fetch( user_url, {
        method: 'GET',
        mode: 'cors',
        credentials: 'include',
        dataType: 'json',
        
        headers: {
            'Content-Type': 'application/json',
            'Authorization': 'Negotiate',
            'Access-Control-Request-Method': 'GET',
            'Access-Control-Request-Headers': 'Content-Type, Authorization, WWW-Authenticate, additional-header',
        },
        
    } )

However the GET for the fetch fails with a "CORS Missing Allow Origin" error even though the pre-flight OPTIONS request succeeds and has the correct "access-control-allow-origin" header in it.

The API site has the IIS CORS Module enabled with an add origin with the URL of the server hosting the page doing the request and the Allowed Credentials="true" option set. The remaining options are set as in the documentation.

CORS settings in web.config for API site

   <add origin="https://intranet.domain" allowCredentials="true" maxAge="120" >		  
          <allowHeaders allowAllRequestedHeaders="true">
			  <add header="header1"  />
			  <add header="header2"  />
		  </allowHeaders>
		  <allowMethods>
			  <add method="GET" />
		  </allowMethods>
		  <exposeHeaders>
			  <add header="header1" />
			  <add header="header2" />
		  </exposeHeaders>
	</add>
```It seems to me that if the pre-flight OPTIONS request should work, the GET should work.

Has anyone gotten this scenario to work? 

Thanks,

Charlotte

Yurong Dai-MSFT 2,781 Reputation points Microsoft Vendor

2024-03-25T09:22:52.2266667+00:00

Hi @Charlotte McClellan,
This document will guide you on how to correctly enable cross-origin requests in ASP.NET Web API: https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/enabling-cross-origin-requests-in-web-api
Charlotte McClellan 20 Reputation points

2024-03-25T13:49:01.7666667+00:00

Thanks for the suggestion but I have been through that document and it is not working.

As you can see from the above screen shot the OPTIONS pre-flight of the CORS handshake succeeds.

And returns the proper headers

Including the correct "access-control-allow-origin' header

But the fetch request does not return the proper headers

And all of the documentation I have consulted including the above link says that if the OPTIONS works, the subsequent GET should work.

Thanks,

Charlotte
AgaveJoe 26,201 Reputation points

2024-03-25T18:40:24.6933333+00:00

According to the to the screenshots a 400 was returned and the 400 response did not have the proper CORS headers. Try reading the response body to get the error.
Charlotte McClellan 20 Reputation points

2024-03-25T19:26:55.0666667+00:00

Thanks. That was very helpful.

The body showed the error "HTTP Error 400. The request was badly formed"

I think the issue was that I was trying to include a "Authorization: Negotiate" header in the fetch call without the appropriate token.

If I remove that header from the fetch, the fetch succeeds and there are no CORS errors but I get 2 authentication popups. One for the Intranet page and one for the API.

Looking at it in Fiddler, it is sending the same NTLM token in both cases.

So the question is how to prevent the second authentication pop or how to capture the NTLM token so it can be included in the header.

Or is this even possible?

Thanks,

Charlotte
Yurong Dai-MSFT 2,781 Reputation points Microsoft Vendor

2024-03-29T09:41:01.23+00:00

Implementing a single sign-on solution could help alleviate the need for multiple authentication prompts. With SSO, the user logs in once, and subsequent authentication requests are handled automatically.

As for capturing the NTLM token, it's generally not recommended due to security reasons. The browser should handle the NTLM authentication process transparently.

Lex Li (Microsoft) 4,742 Microsoft Employee

Your fetch code does not look good (with headers that are not commonly used). Can you just run something like below?


  fetch('/api/v1/user', { method: 'GET', credentials: 'include' })

    .then(response => response.json())

    .then(data => {

      // Handle the data (in JSON format)

      console.log(data);

    })

    .catch(error => {

      // Handle errors

      console.error('Error fetching data:', error);

    });

That should help you pass the authentication.

Charlotte McClellan 20 Reputation points

2024-04-02T14:45:36.3666667+00:00

Hi Lex,

This resolves the CORS error but gives me a second authentication prompt for the API. The more I look into this, the more I think I am going to have to implement a SSO solution. I was hoping for a simple solution but I don't think that is possible.

Thanks for the suggestion.
Lex Li (Microsoft) 4,742 Reputation points Microsoft Employee

2024-04-02T16:47:54.0666667+00:00

The so called "Windows authentication" is actually two (NTLM and Keberos), and Keberos itself is an SSO solution (just over complicated to set up). You might talk to your domain administrators and see if they can guide you through that.
Charlotte McClellan 20 Reputation points

2024-04-02T19:23:10.8966667+00:00

Hi Lex,

I have tried using Kerberos and it only works when logged into a workstation that is joined to the domain. In that case, everything works perfectly. But we need to support people using our Intranet from off-campus.

Thanks for the suggestions.

Charlotte
Lex Li (Microsoft) 4,742 Reputation points Microsoft Employee

2024-04-03T05:32:18.12+00:00

I am not sure if VPN is the option for those people from off-campus, but that's a common way to enable corporate resource access from a remote location and Kerberos should work under that setup. Of course, you might evaluate and adopt other SSO solutions, which often are much simpler than Kerberos, such as Microsoft Entra.

Accepted answer

Bruce (SqlWork.com) 56,026 Reputation points

2024-03-31T16:14:48.13+00:00

Windows authentication is an out of band negotiation. There is no token. A new one is generated on each connection. This supported by the browser. Generally the browser will remember the user/password and reuse on new connections to the same site. If you need CORS then the api is treated as a different site and you need to authenticate once for the site. The browsers handles this.

if you don’t want to login to the site and api, have the main site proxy to the api site. If the api site needs the users id, the proxy code will need to impersonate the user before calling the api. This will work if on the same server. Otherwise you will need to switch to Kerberos and enable delegation.

note: IIS handles the Windows authentication, the core module just passes it to the asp.net app.
Please sign in to rate this answer.

1 person found this answer helpful.
Charlotte McClellan 20 Reputation points

2024-04-01T14:28:12.4166667+00:00

Thanks!

Based on all the comments, it looks like I will have update to a SSO solution.
Sign in to comment

IIS CORS Module configuration with Windows Credentials

0 additional answers