Security |
Impersonation reduces the number of times a user is required to enter a password. However, most services run as LocalSystem, which allows full access. This being the case, how does a service access a resource (such as a file) securely on behalf of the client?
Here’s an example of how impersonation works. Cheryl wants to delete a file called Data.asp. The file is protected so that only the operating system (LocalSystem), administrators, and certain trusted users can access it. Since Cheryl is not on this list of trusted users, it would seem that she cannot access the file.
However, Cheryl can, in fact, delete the file because the application through which she deletes it is actually running under LocalSystem. Since Cheryl has full access, this is obviously not a safe, secure environment.
To safeguard against the file being deleted, all server processes should be configured to impersonate the requesting user before accessing the resource. If the server processes are configured in this way, the server will then impersonate Cheryl and attempt to delete the file. However, this will fail because she does not have delete permission or any other permissions to the file.