How This Page Works

"> B A C K

View Source

How The Site Administration Page Works

Functional Overview

The Site Administration page allows an administrator to set security properties for the Exploration Air sample site. The possible settings relate to authentication and use of the Secure Sockets Layer protocol (SSL).

Changes are made by simply filling out a form and the results are posted back to default.asp where the form data is analyzed and used to set the properties.

Four areas of the site are affected:

Site Administration

Benefits

Frequent Flyer

Business Partners

Site Administration and Benefits are affected as one administrative unit as they are both intranet scenarios. The only setting is whether anonymous access is allowed or not. By default the site should use Windows NT Challenge/Response authentication as it is the most secure.

As Frequent Flyer and Business Partners are Internet scenarios some form of privacy, tamper resistance and/or authentication is required. Internet Information Server support these features by using SSL. SSL supports privacy through data encryption, tamper resistance through message digests and authentication using certificates. The following table explains this in greater detail:

SSL Feature	Comment
Privacy	SSL supports automatic data encryption. Scrambling the data as it passes between the browser and the server reduces the possibility of an eavesdropper working out what is being sent.
Tamper Resistance	SSL supports tamper resistance by using message digests. A message digest is a complex checksum of the data. SSL generates a message digest of the data prior to sending, then recalculates the message digest of the data on reciept. If the data has change (through tampering or communication failure), the checksum will be different and SSL will reject the data.
Authentication	SSL can verify a server using Server Certificates and can verify a client using Client Authentication Certificates. Servers and clients are issued certificates by a certificate authority. Microsoft Certificate Server can behave as a certificate authority.

Components Used

The Active Directory Service API (ADSI) is used as the primary programmatic administration interface for Internet Information Server. With ADSI most aspects of an IIS server can administered programmatically.

Use the following syntax to access the IIS ADSI object from an ASP page, VBScript or JScript:

Set oAdminDir = GetObject("IIS://localhost/w3svc/1/Root/IISSamples/ExAir/SiteAdmin")

Once we have the object properties may be set. For example use the folloing code to set the SSL Client Certificate Required flag on the SiteAdmin object:

oAdminDir.AccessSSLFlags = ACCESS_SSL + ACCESS_SSL_REQUIRE_CERT

A Note On Security

A user must have administrator privileges to access the administration data. This is why the SiteAdmin directory is marked as requiring Windows NT Challenge/Response Authentication, if the user is a Windows NT administrator then this authentication method will preserve their credentials and hence they will be able to access the administration data. If Allow Anonymous is turned on then all access will be attempted as though the user was a member of the Guest group, in other words they will be always be denied access because IIS is logging them on as a guest, not an administrator.

Delegation of User Credentials

Windows NT 3.x and 4.0 do not support credential delegation, in other words you cannot pass the authentication information (called a token) from one application to another. This raises an interesting situation when running out-of-process Web applications (marked as running in a separate address space) in IIS.

If an administrator accesses an IIS Web application and is authenticated using Windows NT Challenge/Response Authentication but the application is marked as running in a separate address space the new Web application will not be running with the same administrator privileges as the user because IIS cannot pass (delegate) the administrator's credentials to the new process. The side effect of this is that if the IIS application is attempting to change IIS data through ADSI it will always fail. The correct way to solve this problem is to make sure any Web application does not run as a separate process.

Please note, because delegation is not supported at present, IIS starts all out-of-process Web applications using the IWAM_xxxxxxxx Windows NT account which is added to Windows NT during setup.