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 admin, it should be a very complex, non-dictionary word, and at least 14-character password that's only used for that box. 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 box admin account is obtained thru privilege escalation attacks, it will reduce the rapidly growing threat surface of the attack. The attacker has to start backover at ground-0 on the pivot because the credentials for domain admins will not be resident on the system from tools like mimikatz or fgdump. Then they have to enumerate and start over from scratch, giving your security operations team time to respond. It's not a lot of time, but enough to detect the service accounts abnormal behaviors.
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 will immediately gain "System" level privileges if an attack is successful.
- Ensure that this system is not trusted 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.)