<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Proget HTTP.Sys vs Kestrel: IP literal behavior?]]></title><description><![CDATA[<p dir="auto">Upgrading ProGet from 2024 to 26.0.10 forced us off IIS onto the Integrated Web Server. The host is shared with another application on port 443, so ProGet uses a hostname binding (<a href="https://proget" rel="nofollow ugc">https://proget</a>.[domain]:443) and the IWS runs on HTTP.sys.</p>
<p dir="auto">Under IIS we had Windows Integrated Authentication on the NuGet feeds with a few feeds (PowerShell via PSResourceGet, npm) exempted for API keys. On HTTP.sys the "Disable On" list and bypassIntegrated=true have no effect, since the Negotiate challenge is issued in the kernel; an exempted feed becomes unreachable for everyone, because Windows callers are treated as anonymous and API-key callers never pass the challenge.</p>
<p dir="auto">A wildcard binding would select Kestrel, but we cannot take the whole port on every IP. If the Web Server URL is bound to an IP literal (https://[second IP]:443) instead of a hostname, does the IWS select Kestrel or HTTP.sys? Is there any supported way to get Kestrel with selective WIA while another application keeps port 443 on the same machine, short of a dedicated host or a non-standard port?</p>
]]></description><link>https://forums.inedo.com/topic/5830/proget-http.sys-vs-kestrel-ip-literal-behavior</link><generator>RSS for Node</generator><lastBuildDate>Fri, 11 Sep 2026 10:46:10 GMT</lastBuildDate><atom:link href="https://forums.inedo.com/topic/5830.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 10 Sep 2026 17:46:47 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Proget HTTP.Sys vs Kestrel: IP literal behavior? on Fri, 11 Sep 2026 03:11:20 GMT]]></title><description><![CDATA[<p dir="auto">Hi <a class="plugin-mentions-user plugin-mentions-a" href="/user/seanl_4808" aria-label="Profile: seanl_4808">@<bdi>seanl_4808</bdi></a> ,</p>
<p dir="auto">First and foremost, we recommend that you move away from Windows Integrated Authentication as <a href="https://docs.inedo.com/docs/installation/security-ldap-active-directory/various-ldap-integrated-authentication" rel="nofollow ugc">Microsoft is discontinuing the technology</a> and move to a modern, more secure technology. It's only going to be a matter of time before WIA stops working altogether due to bugs or removal of support by us or Microsoft.</p>
<p dir="auto">That said, WIA is pretty limited as you can see. However, you can try configuring <a href="https://docs.inedo.com/docs/installation/windows/web/howto-use-iis-as-reverse-proxy" rel="nofollow ugc">IIS as a reverse proxy</a> that forwards <code>https://hostname:443</code> to <code>http/:*:8624</code>; that may also make certificate management easier. We don't have a guide to set that up, however; I'v eonly heard of one customer who made it work somehow with WIA.</p>
<p dir="auto">Thanks,<br />
Alana</p>
]]></description><link>https://forums.inedo.com/post/20007</link><guid isPermaLink="true">https://forums.inedo.com/post/20007</guid><dc:creator><![CDATA[atripp]]></dc:creator><pubDate>Fri, 11 Sep 2026 03:11:20 GMT</pubDate></item></channel></rss>