What architecture shall be used while running this inside Windows container?

[artisticcheese]

Hello,

Currently for managing IIS inside Windows Container I have to include bunch of build steps in dockerfile to provision all the plumbing neccessary for IIS Manager to be able to connect. I'd like to replace it with IIS Administration but I'm confused about how authenticate using token, that is I would like to burn token into running container upon start (passing through environment variable). What I'm missing is to how generate valid token via scripting once container is started based on token value itself.

[jimmyca15]

So you want to be able to generate a token after the container comes online, or do you want to already have a token generated and get the container to use that token?

[artisticcheese]

I want my token which I generate manually to be allowed to be connected to any docker container instance I will launch. So basically the same token will be able to administer any instance of docker container I run in swarm which I can distribute to team members to administer servers when needed.

[jimmyca15]

Okay. When a token is generated two things are created, the access token and a hash of that access token that is stored in the api-keys.json file. If you want to use the same token for all the installations, the hash of that token needs to be inside the api-keys.json file for each one.

So given that you already have an access token, and you know the hash (stored in environment variable) you can write the hash to the api-keys.json file post-install to make the API accessible with that token.

api-keys.json path
c:\Program Files\IIS Administration\<version>\Microsoft.IIS.Administration\config\api-keys.json

[artisticcheese]

What about longevity of tokens?

[jimmyca15]

The have an expiration date.

Example api-keys.json

{
 "keys": [
    {
      "id": "QMWGr6k6WvMM0-aRGHc65g",
      "purpose": "",
      "created_on": "2017-04-26T22:12:35.4529834Z",
      "last_modified": "2017-04-26T22:13:43.7187953Z",
      "expires_on": "2018-04-26T22:12:35.4529834Z",
      "token_hash": "{omitted}",
      "token_type": "SWT"
    }
  ]
}

[artisticcheese]

What about "id" field. Do I generate it to be some random gibberish? Also what do I do with expires_on for "never"?

[jimmyca15]

An empty string value means no expiration
"expires_on": ""

The id field should be an empty string as well.

[artisticcheese]

Thanks. Awesome. The only piece missing is clean installation routine into docker to be proper containerized solution.

[artisticcheese]

What type of hash shall I use on token to put it into json file? MD5, SHA?

[artisticcheese]

This seems not to work. I pushed artisticcheese/iis-basis image along with JSON file. Token is 8UBFSpinXmIvA4cEL_f_aHwP6FADlQTQqXHcKC9b3Gg4ApINx4GJTw and I modifed JSON file per specs above.

{
    "keys": [
        {
            "id": "",
            "purpose": "User1",
            "created_on": "2017-04-26T22:12:35.4529834Z",
            "last_modified": "2017-04-26T22:13:43.7187953Z",
            "expires_on": "",
            "token_hash": "w_DmrAzR8nJ9Kwtg9mx28SWjXXdxOuZqTXN6TkZqmuo",
            "token_type": "SWT"
        }
    ]
}

This does not allow me to authenticate, asks for Windows username/password upon entry. My docker file etc available here https://github.com/artisticcheese/IISadmin

[jimmyca15]

This is because the Windows Authentication requirements that I mentioned here #86 (comment) were not removed.

[artisticcheese]

Enabled as per your instructions (copying entire web.config over). I uploaded new image to docker hub. It's hanging now instead of displaying Windows Prompt.

[artisticcheese]

Also what hash technology is being used? I tried MD5, SHA1, SHA256 and none of those produced hash which I have to put into web.config

[jimmyca15]

You updated artisticcheese/iis-basis?

Access token hashes are created with Rfc2898DeriveBytes. The API uses crypto-agility so in the future we can update the hashing algorithm if necessary and version the access keys accordingly.

[artisticcheese]

Yes, container is updated still not working.

[jimmyca15]

Its running with some modifications I made here https://github.com/jimmyca15/IISadmin/tree/simplify_with_config.

1. The installer was being deleted directly after running because it was executed in quiet mode
2. web.config has restricted ACLs so to overwite that file you must first grant yourself access.

This could be cleaned up more. We can optimize further for containers, feel free to file feature requests that can help in your scenarios.

[artisticcheese]

So the problem was the docker process inside container did not have permission to overwrite web.config file?

[jimmyca15]

That was one of the problems. Also in your container image (artisticcheese/iis-basis) IIS Administration was not installed. It looked like your DockerFile was deleting the setup exe right after invoking it.

[artisticcheese]

This seems to be working without crazy ACL manipulation by using 2 COPY statements - 1 before IISAdmin installation and one after. I assumed first one statement will create entire directory tree with appropriate permissions for web.config and during installation web.config will just inherit parent permissions and then I can replace it second time. To my surprise it worked as expected, so dockerfile is pretty clean now.

1. There is still issue with SSL connection and untrusted cert issued to localhost. It works once I ingnore the issue but wondering how to make it smooth sailing for users.
2. What code can I use to general my own hash to input into configuration?

[jimmyca15]

1. There are still optimizations left to be made for running the IIS Administration API inside containers and untrusted certificates are a prime target.
2. Currently the only way to do this is to use the API to generate a token hash and then use the token-hash pairing. We can create a PowerShell script that generates tokens and put it in the repository as a utility script.

[artisticcheese]

Do I need to create a new issue for point 2? Having PS script to generate tokens will be so much easier then current setup where one have to install it, generate some and go through file system to extract ones.

[jimmyca15]

I believe it would be beneficial. That way we can track it as a feature request and it won't be lost within this thread.

[jimmyca15]

Hey @artisticcheese,

We're in the process of releasing Microsoft IIS Administration 2.0.0. There have been a few changes under the hood regarding the way the API is configured. Most importantly there is no more web.config or applicationHost.config. All of the configuration is now in the appsettings.json file. We would love to see how the new model would work in the scenarios that you have been using the API for. If you're interested let us know. I am currently in the process of drafting the 2.0.0 release on the GitHub repository, but the central download link (the one you have in your container) will not be updated to 2.0.0 for a short time.

[artisticcheese]

Yes, I'm interested in implementing it inside container. is there are chance that installation will be published to Chocolatey or use OneGet provider for powershell and custom repository (like Docker itself does for example https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server).

[jimmyca15]

Okay, I have finished the 2.0.0 release on GitHub. The installer (IISAdministrationSetup.exe) can be obtained from this release, but it is not yet available at the download link you have been using in your containers. The release also documents the biggest change that we have made to the IIS Administration API for this 2.0.0 release, which is the removal of the web.config file and the addition of security configuration in the appsettings.json file. Please let me know if you have any questions.

[jimmyca15]

We did have a discussion regarding Chocolatey and other distribution sources for the installer. We would like to keep the installer at the centralized location we have it now. A quick look over the Chocolatey packages with the Microsoft keyword shows that most of the packages were uploaded by independent users. So we may see someone create an equivalent for the IIS Administration API, but we will not be using it as an official Microsoft channel.

[artisticcheese]

So in 2.0 I can just use Windows Authentication to access IIS administration console? I create local user in docker container during initialization, how do I add that user to allow use IIS administration UI with no tokens? You can see my initial commit under https://github.com/artisticcheese/IISadmin/tree/master/v2

[jimmyca15]

No, an access key is still required with all requests to the API. Even though the api access policy has a boolean value for access_key ("access_key": "true"), it cannot be set to false. It is present there to explicitly show the access key as a requirement.

If you would like to remove the Windows Authentication requirements as before, you can change the api access policy to allow Everyone instead of administrators, and turn off the flag for require_windows_authentication

ex:

"security": {
    "require_windows_authentication": false,
    "users": {
      "administrators": [
      ],
      "owners": [
      ]
    },
    "access_policy": {
      "api": {
        "users": "Everyone",
        "access_key": true
      },
      "api_keys": {
        "users": "administrators",
        "access_key": false
      },
      "system": {
        "users": "owners",
        "access_key": true
      }
    }
  }

[jimmyca15]

@artisticcheese,

Were you able to get running with the new setup?

By the way, to answer your question about the user created during container initialization, if he is added into the security:users:administrators section of the appsettings.json file he will be able to create access tokens.

[artisticcheese]

I'm struggling with AV software fighting with docker, so not sure when I will verify this. Still working on this.

[artisticcheese]

@jimmyca15 Working on implementation and examining appsettings.json shows that some pieces of information in that file seems to be computer specific. Specifically "host_id" property.

1. Can I just create template appsettins.json file and copy it into destination folder since my keys are stored in api-keys.json?
2. Very strange ACLs on config folder. Looks like even local Administrators don't have write access to those files. Is it by design? Local Administrators already have "take ownership" privilige and can override those settings, why this strange setup?

[jimmyca15]

@artisticcheese

1. Yes you can use the same appsettings.json for every installation. The host_id property is used to generate the ids for the JSON resources, but there is nothing wrong with using the same host_id everywhere.
2. The ACLs are in place to force administrators to have to take ownership. Changing the settings within that file can open up the API, which is running as a system account, in many ways so they should not be taken lightly. Our current plan is to make the settings in that file configurable through the API, but have this capability locked down by the system access policy as seen in the security section of the appsettings.

[artisticcheese]

V2 works fine. Uploaded to docker hub and github
https://hub.docker.com/r/artisticcheese/iis-admin/ and https://github.com/artisticcheese/IISadmin/tree/master/v2

[jimmyca15]

Great! By the way. We closed out the bug that you were experiencing with the inability to download freb files, so that should work fine now inside the container.