SetACLCommand

The SetACL command sets restrictive Access Control Lists (ACLs) onto an IdP installation directory tree using repeated calls to the Windows icacls command.

Starting with V5, a new Windows install has no restrictive permissions set. You must not put such a distribution into production and the SetACL command allows you to constrain permissions.

The Shibboleth Jetty installation package uses this command to restrict access appropriately, but if you are maintaining you own container (recommended best-practice), you will need to explicitly restrict access. In such cases is it certain that this command will not do exactly what you need, but it does provide a skeletal example.

Usages

C:\> InstallationDir\bin\setacl.bat [User] [Owner]

The two parameters are both optional and are:

User An account to be given explicit read access to the distribution, and write access to the log folder. This is to allow the web server to be run by a limited permissions user (so the webserver cannot write to the machine), The default is that no user will be specified and the webserver will be run as the default Windows Service account (which is usually highly privileged).

Owner An Identifier which to be made owner for the entire tree. Defaults to Administrators

Details

The batch file is copiously commented; the work is done in 3 stages

1. Ownership of the entire tree is passed to identifier specified in the second parameters (or Administrators). This is needed because if the tree is owned by a user who is going to be denied permission things 'degenerate'.

2. Restrictive ACLs are added to the tree to disallow non elevated access.

   1. In a first pass the directories are restricted. idphome and all the subdirectories are set to allow SYSTEM and Administrators full access (and the provided user read and traverse access). All existing ACLs are stripped and any inheritance is removed at idphome. Inheritance is enabled on these directories, thus files subsequently created in these folders will assume these permissions).

   2. In a second pass all the files below idphome are given the same access as the directories (as noted above)

3. If a User parameter is specified then it is also given FULL access to the directories and files below the idphome\logs directory. This allows a standard IdP Installation to write to the usual place.