User Configuration Settings in ASP.NET Web Applications
Before you go off to implement the techniques shown in this article in your own ASP.NET applications, you must be aware of the way that User Configuration policies work. In general, you should avoid creating GPOs that contain User Configuration settings for web applications (in other words, do not use the CLASS USER
section of an administrative template).
This is because the values you set in Group Policy for User Configuration policies will appear only in the HKEY_CURRENT_USER
hive of the Registry, which gets loaded when Windows loads a user's settings at logon. However, a server may not have a logged-on (current) userand even if it does, the user account will not be the same as the account under which ASP.NET and your Web application are running under (unless you change the default settings for the application so that it runs under the context of the currently logged on user).
The only reason that the user identity appears in Figure 9, and the application reads the Group Policy settings defined in the CLASS USER section of the administrative template, is because the application is running within Visual Studio 2005 under the context of the currently logged on user (alex in this case). You can see that the URL contains the custom port number for the Visual Studio Web Server.
If you install the application into Internet Information Services, and run it from there, you will see that there is no "current user" and the Group Policy settings in the CLASS USER section are not available (the user name and user location values are those contained in Web.config), as you can see in Figure 10.
|Figure 10. Running under IIS: When running under IIS rather than the Visual Studio Web Server, notice that there is no "current user," and the values for "User name" and "User location" revert to those in Web.config.|
If you disable anonymous access so that users must provide valid Windows account credentials to run the application, the page does show the user name as the current identity; however, it still
does not use the Group Policy settings from the CLASS USER section of the Administrative Template, because the user is not actually the "current user" on the machine.
Therefore, you should only use the CLASS USER
section of the Administrative Template for Windows Forms or other applications that will always
run under the context of the currently logged on user, and not in ASP.NET Web applications.
Manageability Is Key
In this article, you've seen how you can use Windows Group Policy to centrally manage configuration information and impose specific values on all machines and users. By using these techniques within a custom configuration provider, you can easily build Group Policy-aware configuration systems that support centralized administration and control.
In the final article in this series, I'll demonstrate how a "real world" application uses these techniques by showing how version 3.0 of Microsoft's Enterprise Library provides the same kinds of centralized administration capabilities through its Manageable Configuration Provider mechanism.