Why Authorization Data Is Signed

  • Article

Session tickets are encrypted with the secret key for the account under which the service starts. When a service acquires a handle to its own credentials on the system, it gains access to that secret key. The difficulty is that an unscrupulous user with a legitimate network account but limited authorization on the local computer could install a rogue service on the computer. This user could request a session ticket for the service, and the service could decrypt the ticket, modify the authorization data by adding the SID for a privileged group, encrypt the altered ticket, and present it to the LSA in a call to AcceptSecurityContext. The result would be to elevate the user's level of authorization on the computer where the service is running.

To prevent tampering, authorization data is signed by the KDC before it is stored in a session ticket. Any attempt to alter the data invalidates the signature. The LSA on a Windows 2000 computer always checks the signature on authorization data in session tickets that untrusted services present in calls to AcceptSecurityContext. As far as the LSA is concerned, an untrusted service is any service that is not running under the Local System account. This account is used by services installed with the operating system — by the native Server service, for example. Other services can be configured to use the Local System account, but this must be done by a member of the Administrators group. The assumption is that the administrator who installs the service can vouch for its security.

If a session ticket is presented by an application that is not running as Local System, the LSA asks the KDC in its domain to verify the signature on the ticket's authorization data. The question is asked and answered by an RPC over Net Logon's secure channel to the domain controller. Requests for verification do not need to travel beyond the local domain because session tickets are always issued — and, therefore, authorization data is always signed — by the KDC in the destination computer's domain.