IIS 7.0 : Web Management Service (part 2) - Managing Remote Administration

Managing Remote Administration

The previous section focused on tasks to enable the service and get you started. This section covers the set of tasks you need to perform regularly for remote administration, for example, adding new users, granting permissions, and customizing delegation for them.

Managing Users and Permissions

The procedures to manage users and permissions vary depending the type of authentication option you choose. The following are not detailed provisioning guidelines, but instead are some of the steps required to provision a simple site. For more information on provisioning guidelines, search for Secure Hosting on http://iis.net.

Windows Credentials

With Windows users, you can use any of the native Windows tools to create and manage users. Windows users that will manage only sites or applications do not need to belong to the administrators group or any other group. One easy way to add users is using the command line tool Net.exe. For example, to add a new local Windows user, DelegatedUser1, you can just run the following command line.

net user /add DelegatedUser1 Str0ngP@ssw0rd!

Now, you can create a site called DelegatedUser1Site and protect the content and configuration for this user so they can edit the settings. The following command lines create a directory, grant modified permissions for the user to that folder, and finally register the folder as a site in IIS 7.0 via Appcmd.

Mkdir c:\Sites\DelegatedUser1Site
icacls c:\Sites\DelegatedUser1Site /grant DelegatedUser1:(OI)(CI)(M)
%windir%\system32\inetsrv\appcmd.exe add site /name:"DelegatedUser1Site"/
physicalPath:c:\Sites\DelegatedUser1Site /bindings:http/*:8080:

Note

Long commands are sometimes shown formatted on multiple lines to fit on the printed page.

Finally, with the user and the site created and configured, you can go to the IIS Manager Permissions feature and grant access to this newly created user to manage its own site. This task can also be automated by using Managed Code and calling the Microsoft.Web.Management API.

The following steps will grant permissions to connect to the site DelegatedUser1Site for the user DelegatedUser1:

1. From the Administrative Tools program group, launch Internet Information Services (IIS) Manager.

2. In the Connections pane, expand the IIS computer node and then expand the Sites node and click DelegatedUser1Site in the tree view.

3. Double-click the IIS Manager Permissions feature.

4. In the Actions pane, click Allow User, type DelegatedUser1 in the Windows text box, and then click OK. Note that in this text box, you can also specify the name of a group to allow entire Windows groups at once.

Figure 7 shows the Allow User dialog box. Notice that if only Windows credentials are enabled in the Management Service page, an informational alert is displayed at the top of the Actions pane and the IIS Manager option will be disabled in the Allow User dialog box. You can also use the Select button to search for existing Windows users and groups.

Figure 7. Allow User dialog box for Windows users.

After following the preceding steps, the user DelegatedUser1 will be able to use IIS Manager remotely or locally to connect to this site and manage it successfully.

IIS Manager Credentials

With IIS Manager credentials, you can use IIS Manager to manage the users. This functionality is built using an extensible architecture through a provider-based model. The built-in functionality uses Administration.config to store the user name and the SHA256 hash of the password, so it is not as straightforward as using Notepad to edit Administration.config and add users. We recommended two ways of adding users: use IIS Manager or use the underlying managed code API (Microsoft.Web.Management). Luckily, calling managed code objects is easy using Windows PowerShell, and we will see how you can use it to manage the IIS Users without having to use IIS Manager. Following is an example similar to the one we looked at before, in which we create a new IISUser1 and provision a new site for it. This way, IISUser1 can manage the site successfully.

First, we create a site called IisUser1Site and protect the content and configuration for NT Service\WMSvc to be able to edit the settings. The following command lines create the directory, grant modify permissions for the service to that folder, and finally register the folder as a site in IIS 7.0 using Appcmd.

Mkdir c:\Sites\IISUser1Site
icacls c:\Sites\IISUser1Site /grant "NT Service\WMSvc":(OI)(CI)(M)
%windir%\system32\inetsrv\appcmd.exe add site /name:"IISUser1Site"
/physicalPath:c:\Sites\IISUser1Site /bindings:http/*:8081:

Finally, using the IIS Manager Users and IIS Manager Permissions features, we create the user and assign permissions for it.

1. From the Administrative Tools program group, launch Internet Information Services (IIS) Manager.

2. In the Connections pane, select the IIS computer node and double-click the IIS Manager Users feature.

3. Click Add User from the Actions pane, type IISUser1 in the User Name text box, provide and confirm a strong password, and then click OK.

Figure 8 shows the Add User dialog box.

Figure 8. Add User dialog box.

After creating the user, you can go to the site and use the IIS Manager Permissions just as with Windows users to grant access to it.

The following steps will grant permission to connect to the site IISUser1Site for the user IISUser1:

1. From the Administrative Tools program group, launch Internet Information Services (IIS) Manager.

2. In the Connections pane, expand the IIS computer node. Then expand the Sites Node and click IISUser1Site in the tree view.

3. Double-click the IIS Manager Permissions feature.

4. Click Allow User from the Actions pane and select the IIS Manager option. Then type IISUser1 in the text box and click OK.

Figure 9 shows the Allow User dialog box with the IIS Manager option selected. Note that you can click the Select button to get a list of the existing IIS Manager users.

Note

When using the IIS Manager Permissions page to grant access for IIS Manager Users, you need to make sure that the Management Service has been configured to enable Windows credentials and IIS Manager credentials. Otherwise, the IIS Manager option is disabled in the Allow User dialog box.

Figure 9. Allow User dialog box for IIS Manager users.

After following the preceding steps, the user IISUser1 is granted access to its site, and because we are using the built-in authentication, it is stored in %SystemRoot%\System32\Inetsrv\Config\Administration.config by using syntax similar to that shown here.

<system.webServer>
    <management>
        <authentication
            defaultProvider="ConfigurationAuthenticationProvider">
            <providers>
                <add name="ConfigurationAuthenticationProvider" type="Microsoft.Web.Management.
Server.ConfigurationAuthenticationProvider,
..." />
            </providers>
            <credentials>
                <add name="IISUser1" password="DE499719..." />
            </credentials>
        </authentication>

        <authorization
           defaultProvider="ConfigurationAuthorizationProvider">
            <providers>
                <add name="ConfigurationAuthorizationProvider" type="Microsoft.Web.Management.
Server.ConfigurationAuthorizationProvider,
... " />
            </providers>
            <authorizationRules>
                <scope path="/DelegatedUser1Site">
                    <add name="CONTOSO\DelegatedUser1" />
                </scope>
                <scope path="/IISUser1Site">
                    <add name="IISUser1" />
                </scope>
            </authorizationRules>
        </authorization>
...

Using Windows PowerShell to Manage IIS Users and Permissions

The best way to automate the creation of IIS users or to assign IIS Manager permissions to either Windows users or IIS users is to use the underlying API that is exposed by the IIS Manager extensibility model in Microsoft.Web.Management. In this case, there are two static classes you can call to manage the authentication and authorization for IIS users. Luckily, Windows PowerShell makes this really simple.

To create a new IIS User, IisUser2, and grant permissions for it to connect to the site, IisUser1Site, you can execute the following commands inside a Windows PowerShell console.

Note

Windows PowerShell is included as an installable feature of Windows Server 2008, and you can install it using Server Manager.

# First Load the Microsoft.Web.Management Assembly
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Web.Management")
# Create another IIS User
[Microsoft.Web.Management.Server.ManagementAuthentication]::CreateUser("Iis
User2", "Str0ngP@ssw0rd!")
# Assign Permissions for it to connect to the IisUser1Site Web Site
[Microsoft.Web.Management.Server.ManagementAuthorization]::Grant("IisUser2",
"IisUser1Site", 0)

Because this API internally uses the configured provider in Administration.config to process the calls, it will correctly store the settings regardless of the provider store. Therefore, it will work correctly independent of the fact that it should be stored in Administration.config or the password should be stored in SHA256. If a developer creates his own authentication or authorization provider, the preceding code will work correctly against their users’ stores, whether it is a database or something else.

Feature Delegation

The previous section discussed how to create users and grant them the ability to connect remotely so that they can manage their sites and applications. However, nothing has been discussed about what settings they should be able to see and configure after they are connected, and how you can customize that. It is now that feature delegation comes into play.

Feature delegation gives you the ability to configure what options the users should not be able to see when they connect, which features should be read-only, and which features they should be able to change. For example, you could specify that all the sites should be able to modify the Directory Browsing settings and have only read access to the CGI settings. But at the same time, you might want to specify that users of a particular site or application can change the CGI settings and that other applications should not be able to see the CGI settings (and thus you should entirely remove it from their view).

Figure 10 shows the Feature Delegation page with the default settings for all the sites on the server.

Figure 10. Feature Delegation page.

This page has two modes of operation. The first is the Default Delegation mode, which is shown when you first access the page, and which enables you to specify the delegation state for all the children of the current selected object. For example, Figure 10 shows the default settings for all the sites in the server. The second mode of operation is called Custom Site Delegation, and it enables you to choose the specific site or application on which you want to configure the delegation state. Figure 11 shows the Custom Site view. Notice the Site drop-down list, which enables you to select the site that you want to customize. Any changes will impact only the selected site or application and its children.

Figure 11. Custom Site Delegation page.

Delegation States

The Delegation column in the Feature Delegation page specifies the delegation state for each of the features. It can contain values that enable you to specify various items, including whether or not a feature should be visible to its child sites or applications. Table 3 shows the possible values and the behavior of all of the built-in features in IIS Manager.

Table 3. Delegation States

Delegation	Description
Read/Write	Completely delegated, and users can modify the feature settings. If the feature uses configuration sections, these sections will be unlocked so that they can be used within the Web.config files in the sites, applications, or folders below the current object. Unlocking the configuration sections will also cause IIS Manager to store all the settings in the deepest configuration path possible, saving settings for a site or applications in their Web.config files.
Read-Only	Read-only so that delegated users can only look at the feature settings but not change them. If the feature uses configuration sections, they will be locked so that they cannot be used in the Web.config files below the current object. Locking their configuration sections will cause IIS Manager to store all the settings for child objects in the current configuration path and use location paths within that configuration file for the objects. For example, marking a feature as Read-Only at the server level will cause all the settings for the sites and applications to be stored in ApplicationHost.config using the location paths instead of saving them in their Web.config files.
Not Delegated	Not shown to delegated users. If the feature uses configuration sections, they will be locked just as for Read-Only. In addition, the feature will be removed in Administration.config so that it is not shown to the user.
Configuration Read/Write	Same as Read/Write except it is used for features that also have settings or data that is stored and managed outside IIS. It is used for features such as ASP.NET Roles and ASP.NET Users that specify some of these features’ settings, such as the provider to be used in the configuration system. However, the specific provider handles the actual data, and IIS Manager cannot protect the data. In this case, Configuration Read/Write means that changing the configuration aspect of the feature will be enabled for delegated users, and its configuration sections will be unlocked so that they can be set in their Web.config files.
Configuration Read-Only	Same as Read-Only, except it is a special delegation state used for ASP.NET features that have some of their settings in configuration and some of them on a different store, for example, databases. In this case, Configuration Read-Only means that the configuration aspect of the feature will not be allowed for delegated users, and its configuration sections will be locked. However, the data that the provider manages might still be modifiable by the user.

Note

The list of delegation states varies depending on the feature being managed, because each feature individually provides the delegation states and their settings, and—when using third-party features—their values and their behavior could be implemented differently from the ones specified previously.

As mentioned in Table 3,  as well as the extensibility of IIS Manager in Administration.config. It is important to emphasize that IIS Manager uses the configuration settings to determine where to save configuration settings for each of the features. To help figure out where the settings are being saved, IIS Manager will show in the status bar a textual indication of the configuration file that will be modified when changes are performed.

Figure 12 shows how the status bar is displayed when you’re managing a feature for an application called BlogApp under Default Web Site, which is delegated. In this case, the settings will be stored in the Web.config of the application.

Figure 12. Status bar indicating changes stored in Web.config.

Figure 13 shows how the status bar is displayed when you’re managing a feature for an application called BlogApp under Default Web Site, which is not delegated. In this case, the settings will be stored in applicationHost.config, and a location path Default Web Site/BlogApp will be used.

Figure 13. Status bar indicating changes stored in applicationHost.config.

When managing the server, you see the feature delegation page only at the server level, and it enables you to customize the delegation settings only for the sites. To customize the delegation settings for applications, you need to connect directly to the site that you want to manage by using the IIS Manager Connect To A Site option. After it’s connected, you see the Feature Delegation page at the site level, and it lets you change the settings for all the site’s applications. Alternatively, you can use Custom Application Delegation to change settings for a specific application.

The Custom Site Delegation page also enables you to copy settings from one site to another. (This functionality is also available in the Custom Application Delegation page.) This is a convenient way of easily ensuring the same level of delegation is used among two sites without altering the default settings for the rest of your sites. Figure 14 shows the Copy Delegation dialog box. In this case, the Delegation settings of the site IisUser1Site will be copied to the site DelegatedUser1Site.

Note

The delegation configuration is stored in both Administration.config and applicationHost.config. This means that when Shared Configuration is enabled, the delegation configuration is automatically shared by all the servers configured to use Shared Configuration because they all share both files.

Figure 14. Copy Delegation dialog box.