That sounds super sketchy man. The policy is right... Sounds like an app I'd like to deploy and test my pentesting skills on. :)
I'd go with the policy and push on the devs to provide a standard hardening guide to the minimum rights possible to avoid vulnerabilities to your host and ultimately your entire network if the host is compromised. Weak vulnerabilities in a web application could allow a hacker to generate shell to run commands on your host, gain a foothold in your network, and begin attacks within your network...
I would probably test it in a dev lab server... keep tweaking and hardening with basic user rights. Then keep hardening until the application breaks. Once hardened, you should only use a non-domain admin account on the box. Most importantly with a non-domain user, it should be a very complex, non-dictionary word, and at least 14-character password that's only used for that account. Avoid credential recycling.
Then when you login as the admin after all domain creds have been cleared and the box has been hardened, if the a local admin account is obtained thru privilege escalation attacks, it will slow the threat actor mildly by not being able to immediately pivot to another host. The attacker has to start backover at ground-0 on the pivot. Your security operations should catch them by then if they're monitoring for commands that shouldn't normally be running outside of a scheduled change window. It's not a lot of time, but enough to detect the service accounts abnormal behaviors of running various commands it wouldn't normally.
If you're just looking for a basic set of instructions on how to start basic hardening work in Windows. You may want to take a deep-dive and experiment with an Isolated Dev box for Windows until you have your hardening down. Just setup IIS with a basic "Web shell" and lock it down until your web shell is almost useless. You can google "ASP Webshell" and it will give you some code to test in IIS. Then remove the webshell from the system entirely! <- very important for obvious reasons!
Keep tuning your hardening until you're ready to make your production setup run and make sure you take lots of notes. I'm sure there are guides out there and MSDN has a lot of resources to assist.
Basic overview of what you'll be doing... this is mostly ran off of memory of essential basics, please check out hardening guides from CIS for more fine-grained policy recommendations.
- Create a functional account
- Remove User rights to that account
- Preferably on-board that account into a password solution like CyberArk
- Create a security group for "Run as a Service" rights
- Open SecPol and remove all rights to Run as a Service except your new security group
- Add that functional account to that security group
- Restrict that security group from a lot of basic user functions other than minimum requirements
- Configure IIS and the Application Pool services to run on these restricted accounts and never trust the app to run with "network services" because an attacker could potentially use "Network Services" to reconfigure a Service and elevate to "System" level privileges if is successful.
- Ensure that this system is not trusted or a delegate for any AD Privileges.
- Harden the file system from that service account and only allow it access to the minimum amount of data required to operate. (.Net Libraries as needed, IIS logging, etc.)