Authentication
Authentication |
|
In Windows 2000, any entity that can initiate action is a security principal. Thus, security principals can be either human users or inanimate entities such as computers or services ("daemons," if you are from the UNIX world). Security principals establish a context for their actions by presenting credentials from a security authority that is trusted by the LSA on the computer where the principal intends to act.
For example, Windows 2000 computers participate in a network domain by communicating with a domain controller, and they do this even when no human user is logged on. To initiate communications, the computer must have an account in the domain and must present credentials to prove that it is the account holder. Before accepting communications from the computer, the LSA on the domain controller authenticates the computer's identity just as it would for a human security principal.
Although most Windows 2000 applications run in the security context of the user who starts them, this is not true of services. Windows 2000 services are started by the service controller, often automatically when the computer starts. They continue to run long after the last human user has logged off. Services have to log on to domain accounts to gain access to domain resources, just as human users and Windows 2000 computers do. Before starting a service, the service controller logs on to the account designated for the service and presents the service's credentials for authentication by the LSA.
For example, when a Windows 2000 computer joins a domain, the Net Logon service on the computer connects to a domain controller and opens a secure channel to it. To obtain an authenticated connection, Net Logon must have credentials that are trusted by the remote computer's LSA. It uses credentials for the local computer's domain account, just as all other services running as Local System do. Any service not running as Local System must have its own domain account.