Impersonation Basics

Let's assume that we are creating a server application that will access certain directories on behalf of the clients using the server. One example of this kind of application is Internet Information Server (IIS). Depending on certain security settings (which I'll discuss later in this chapter), IIS has two choices:

• It can act under the authority of a single user that has been configured as a system " user " with the necessary rights to access the required directories.
• It can act as an authenticated user who has a user account on the Windows 2000 server or Windows NT domain or Active Directory.

When using the second method, does IIS need to check every request to explicitly verify permission? Quite simply, the answer is no.

I have no access to the source code for IIS, but I imagine the IIS developers use impersonation to allow the server to behave as if the client user were actually making the request directly. This is a clean way to enforce security, and at the application level most of the effort involves beginning the impersonation and then simply doing what the application would normally do. Normal error handling will catch the errors that could occur when the user being impersonated does not have authority on the server to perform the requested task. Allowing the standard Windows 2000 security model to handle enforcement of permissions is an ideal way of ensuring the correct access for all clients. I don't have the source code for Microsoft SQL Server either, but based on information in Inside Microsoft SQL Server 7.0, by Ron Soukup and Kalen Delaney (Microsoft Press, 1999), we can see that the mechanism used internally for much of the client/server communication uses Remote Procedure Calls (RPC). I would presume that since using the Windows 2000 user authentication is one option, SQL Server uses the RPC impersonation functions that I discuss in the next section.