The more accepted method to do this is to use Application Request Routing (ARR) - but this requires setting up an additional AD FS (Active Directory Federation Services) Server.
I was recently looking to do the same as you for an instance of Kibana, and happened to find this help blog: https://www.smbadmin.com/2017/07/securing-kibana-with-iis-reverse-proxy.html
As links are not considered a good answer on stack, I'll summarize:
- Install IIS with Web Server role along with URL Authorization, Windows Authentication, and Management Tools.
- Configure the IIS Reverse Proxy with the URL Rewrite module. This can require some tinkering, depending on the nature of the website/web app on the backend, and in some cases it can completely fail (more about that later).
- Setup SSL (Optional) - The proxy accepts traffic coming in via https - and the backend can use http because it is a private connection. A good way of securing sites/apps that aren't SSL enabled.
- Setup Authentication - using the Authentication module for the IIS website, disable anonymous and enable preferred method, in my case "Windows Authentication".
- Setup Authorization Rules - Delete the allow all default rule and add an allow rule for the AD users or groups that should have access.
So, this worked great for my Kibana installation, so I decided to deploy it for Jenkins and a number of other websites and web applications, with some tweaks I got most working.
However, caveat - some sites I tried this with, just would not take - Confluence for example, the authorization popup would continually come up on every page refresh. Another obscure, custom web app that is closed source, used some poor web development practices that could continually cause 500 and bad redirects.
I may try setting up ARR in the future to see if that works better in these instances, but ARR is outside the scope of your original question.