Moving from IIS to Integrated Web Server

[caterina]

Hi all,

we are trying to update from ProGet 2024 to ProGet 2025.
As I understood the documentation we have to move from IIS to integrated web server.
Right now we are running ProGet on two IIS sites. One where windows authentication is enabled and one where it is disabled (necessary for npm).
Is this still possible when moving to Integrated Web Server?
We need to keep the windows authentication but I am not sure if our npm tasks will continue working.
Maybe you can clarify that for me.

Thanks,
Caterina

[stevedennis]

Hi @caterina ,

First and foremost, Microsoft has effectively discontinued Windows Integrated Authentication (WIA) in favor of more modern and secure environments. As such, we strongly advise taking this opportunity to simply move away from it.

Our recommended environment is:

• No authentication required to view/download packages
  • the only exception to this is packages containing things like trade secrets.
  • that should not be the default, as "when everything is secret nothing is"
• API Key required to publish packages
  • minimal permissions (i.e. no overwrite)
  • limit to feeds when appropriate, so you don't have too many keys
  • consider rotating annually

That said, WIA is still supported in the Integrated Web Server and unsupported feeds (like npm) are automatically excluded from WIA when Kestrel is used (i.e. when you are NOT doing port sharing, and binding to a port). You can also explicitly exclude NuGet feeds.

However, it's not possible to do "authentication by port", like what was possible by creating two sites in IIS.

Hope that helps,
Steve

[caterina]

Hi @stevedennis ,

thank you for your reply. I still have some questions.

When talking about WIA are you only talking about NTLM?
What we do is using Kerberos to make sure specific AD-groups have access to our packages. Not everyone is allowed to view/download packages. Going with no authentication is not an option for us.
I can not find a documentation that states that Kerberos is discontinued. Maybe you can provide me with sources? Or maybe we are talking about different things when talking about WIA

Right now our process is that a user is authenticated if he is in a specific AD group and wants to access nuget packages, and he needs an api key to access npm packages.

If I install ProGet 2025 with integrated web server and activate WIA in the settings, I am no longer able to make e.g. "npm i" because the authentication fails:

Which makes sense, because npm is not supporting WIA, but I was hoping ProGet manages this under the hood when switching to integrated web server.

Our ProGet instance is bound to a hostname and a port.

I already tried to explicitly disable WIA for our npm feeds, but it does not seem to be working.

Is there another setting I am missing?

Thanks,
Caterina

[stevedennis]

Hi @caterina,

I was referring to Windows Integrated Authentication (WIA) in general; while it's not "formally deprecated" yet, a lot of Microsoft's guidance and support it's basically treat it as a legacy technology used for existing internal intranet scenarios (especially now that NTLM has been disabled by default), and Microsoft’s modern web application guidance explicitly recommends token-based authentication instead.

So, that drives our guidance as well.

In any case, it sounds like you're doing port sharing:

Our ProGet instance is bound to a hostname and a port.

If you can bind it to just a port, then this should work. The reason is that hostname-binding requires operating system components (i.e. HTTP.SYS) to handle the request, and ProGet cannot disable it on a per-url basis.

Thanks,
Steve

[caterina]

Hi @stevedennis ,

the thing is that microsoft states that windows authentication is great for internal applications integrating the Active Directory: https://learn.microsoft.com/en-us/aspnet/core/security/authentication/windowsauth?view=aspnetcore-10.0&tabs=visual-studio
I can not find a documentation telling me to switch to token-based authentication.
It is also easier to maintain, because the AD is already managed. To manage tokens for each person that is allowed to access ProGet would take up extra effort.

Either way, we moved away from hostname-binding and then we are able to use "npm install" for example.
But a new problem occured:
If I go to the ProGet UI, into one of our npm feeds and try to download a npm package using the download button, i get an Unauthorized error:

So I can see the packages, but I can not download them, eventhough the permission is "View and Download packages"

Can you help me here as well?

Thanks,
Caterina

[stevedennis]

Hi @caterina,

Well, it's Microsoft, so their teams and guidance is all over the place... and that article is "AI-assisted" (labeled as such), so it's probably even more inconsistent than Microsoft's normal docs :)

But, I definitely agree on the convenience of WIA over tokens. In any case, we don't have a plan to discontinue it from our products - but it is a "risky" feature, both in terms of making ProGet less secure and regressions (from Windows updates, or client/ProGet upgrades). So that's why we encourage users to move away.

Anyway.... as for the issue, can you try adding ?bypassIntegrated=false to the URL? We are linking directly to the NPM API, which is bypassed. I'd like to see if that solves it.

Thanks,
Steve