How Services Use Authorization Data
In Windows 2000, services act in their own security contexts only when they are trying to gain access to resources on their own behalf. For the most part, this happens only when they are doing their own housekeeping — reading or writing configuration data stored in registry keys, binding to communications ports, and completing other tasks that are not related to work for a particular client. When a service is doing something for a client, it impersonates the client and acts in the client's security context. This means that in addition to verifying the identity of a client, Windows 2000 services also must take on some of their client's characteristics — specifically, the client's level of authorization on the system.
When a service sets up housekeeping on a computer that is running Windows 2000, it calls the SSPI method AcquireCredentialsHandle to gain access to its own credentials (the secret key for the account under which the service runs). The service then binds to a communications port, where it listens for messages from prospective clients.
When a client requests a connection and presents a session ticket, the service asks the Kerberos SSP to verify the client's credentials by calling the SSPI method AcceptSecurityContext and passing as an argument the client's session ticket along with a handle to the service's secret key. The SSP verifies the ticket's authenticity, opens it, and passes the contents of the authorization data field to the LSA. If the data includes a list of SIDs, the LSA uses them to build an access token that represents the user on the local system. In addition, the LSA queries its own database to determine whether the user or one of the user's security groups is a member of a security group created on the local system. If any such groups are found, the LSA adds these SIDs to the access token. The LSA then confirms for the calling service that the client's identity has been authenticated and encloses a reference to the client's access token.
Upon receiving confirmation, the service completes its connection with the client and attaches the client's access token to an impersonation thread by calling ImpersonateSecurityContext. When the impersonation thread requires access to an object, it presents the client's token. The operating system performs an access check by comparing the SIDs in the client's token to the SIDs in the object's ACL. If the operating system finds a match, it checks to see that the entry in the ACL grants the level of access requested by the thread. If the authorized level of access matches the level of access requested, the thread is allowed access to the object. Otherwise, access is denied.