-3

I am running a windows 2016 server, we are running IIs 10 on it and i need to be able to assert if there is an AppPool setup before i deploy a website. If it doesn't exist i need setup the AppPool with a specific user and password.

All of this is done using a release agent through Azure Devops.

The agent is running as a NON-ADMIN, and i all accounts involved are running as NON-ADMIN. I have no intention at all to run any admin accounts, for security reasons i want to give least privildges to all accounts involved.

when i try to set up a AppPool using appcmd.exe i get the error msg:

KeySet does not exist.

When running everything as admin it works (and i have absolutely no intention in running any of this as admin).

What i have tried: i have added the non-admin account to the IIS_IUSRS group.

Made sure that the user has read permissions to the file: 76944fb33636aeddb9590521c2e8815a_GUID in the %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys folder.

i have tried everything here: Error when you change the identity of an application pool by using IIS Manager from a remote computer

anyone that actually knows the cause of this problem?

UPDATE:

Microsoft clearly recommends that agents should be run using service accounts, which i am doing and i have no interest in giving build agents administrative rights to 1000s of servers when they clearly don't need that kind of powers actually. I want to restrict their powers to only be allowed to do what they need to do. I can't believe that giving everything admin is apparently the norm.

Toerktumlare
  • 12,548
  • 3
  • 35
  • 54
  • Th rule of thumb here is that all IIS configuration API assumes you use an administrator account. You cannot fight against something out of your control. – Lex Li Oct 02 '20 at 15:37
  • which is from a security perspective HORRIBLE. I have no interest at all giving build agents administrative powers. Even microsoft themselves recommend not running deployment agents with administrate privileges. So how can Microsoft clearly recommend a behavior which is impossible to uphold then? How should one automate the entire process, if microsoft recommends not using administrative accounts which i completely agree upon. – Toerktumlare Oct 02 '20 at 17:29

1 Answers1

3

After a lot of googling, and i mean A LOT. I managed to solve this. And let me say, that it baffles me that "least privileged accounts" is not common practice in the Microsoft and windows world.

I found this excellent post by InfoSecMike locking down azure devops pipelines.

And we both have the exact same requirements and opinions on this topic.

You CLEARLY don't need admin rights to update IIs configurations (because that would be insane, right!?). The IIs configuration API does not care what rights you have, what you do need is access to certain files. But this is not documented. Microsoft themselves, just for simplicity, tells you that you need to be admin, and buries all the details really deep in documentation when this should be best practice. Also what amazes me is that no one questions it.

What you need is the following:

  • full access to C:\Windows\System32\inetsrv\Config
  • full acccess to C:\inetpub
  • read access to three keys in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\
6de9cb26d2b98c01ec4e9e8b34824aa2_GUID (iisConfigurationKey)
d6d986f09a1ee04e24c949879fdb506c_GUID (NetFrameworkConfigurationKey)
76944fb33636aeddb9590521c2e8815a_GUID (iisWasKey)

The 2 first bullet points can be obtained if you make sure your service account is a member of the group IIS_IUSRS.

This group will not give you access to the keys. You need to manually give read permissions to these 3 keys to the agent user.

If you don't give access to these keys you will get the obscure error message

Keyset does not exist ( exception from HRESULT : 0x8009000D)

Which is an incorrect error if you ask me as it should be an IllegalAccessException with proper reason telling you that you don't have access to read the key because the keys are there, they do exist (nice code microsoft, maybe you should open source this so we can fix).

I'll leave with this quote from infosecmike.

The goal was to lock down the permissions of the Azure Pipeline Agent {...}. I started Googling, pretty sure I would find a way to achieve this goal. I didn’t. It’s surprising to not find an answer about this. It seems like the principle of least privilege does not apply anymore in a devops world.

This is why i prefer Linux over Windows. This is a simple task there.

Toerktumlare
  • 12,548
  • 3
  • 35
  • 54