The logon procedure on a terminal server client is basically the same as the procedure under Windows XP. However, a network connection between client and server is involved, and this can be critical from a security perspective. We will now take a closer look at some terminal server logon basics to gain a better understanding of the entire procedure.
Logging on to a computer running Microsoft Windows XP or the local Windows Server 2003 console requires three keys to be pressed
Figure 8-1: Logon screen for logon to a terminal server from a Terminal Services client.
Using terminal server clients in combination with terminal servers is, of course,
Starting a new Windows Server 2003 terminal server session naturally requires the same logon procedure as the local console session. This is why it is necessary to find an alternative for the secure path and the security screen. As a consequence, connecting to a terminal server leads directly to the logon screen in most cases.
Windows Server 2003 now allows the use of smart cards for Terminal Services. If you use a Terminal Services client that supports this option (for example, under Windows XP), the corresponding logon data is transmitted to the terminal server via a virtual RDP channel and the user credentials are evaluated there. This is how authentication for terminal server environments becomes more secure.
After logging on, users interact with their individual work environment until they log off or want to change a security-relevant feature of the environment. The secure path must always be available for activation from the client and must always lead to a security screen. For this reason, alternative key combinations, menu items, or special client programs are permitted.
Figure 8-2: On a Terminal Services client, the secure path is available through a special option in the Start menu (bottom right). This entry is visible only on the client, not on the local console session.
The security screen is displayed within the trusted context of a special session that does not permit any connection to other processes. The screen therefore allows a number of security-relevant actions with low risk of unauthorized access:
Changing the password. The password can be either for a local or a network- based user account.
Password-protected locking of the screen and all input devices. The secure path unlocks the screen and devices.
Logging off the current user.
Shutting down the computer. The user must have the corresponding permissions.
Observing and modifying all processes the user works with.
Only an administrator can modify, to a limited extent, the appearance and responses of the security screen that receives the logon information. Most functions are, however, predetermined by the system.
The appearance and functionality of the security system are determined by a system component called graphical identification and authentication (GINA) DLL. The GINA DLL communicates with the security monitor, implements network access to user accounts, and handles password encryption. Msgina.dll, the standard GINA component, is, in part,
Figure 8-3: The Windows security dialog box on a Terminal Services client. Depending on permissions, the user will or will not be able to shut down the computer.
If security concerns exist when using alternative logon
The Shut Down... button of the security screen holds unexpected functions in terminal services sessions, including, for instance, disconnecting the session or user
At the beginning of a local Windows Server 2003 logon procedure, the password entered together with the user name is encrypted and compared to a reference saved on the system. After successful authentication, the WinLogon process creates an access token based on the user s security identification (SID). Subsequently, an access control list is generated that has the same structure as the SID. WinLogon derives the access token from the security subsystem, which, in
Naturally, the Security Account Manager for local user accounts is an
By taking a closer look at the extended security attributes of the registry, you will recognize the SAM database access options:
Query value system only
Set value system only
Enumerate subkey system only
Notify system only
Create link system only
Delete system only
Write DAC (access control list) system and administrators
Write owner system only
Read control system and administrators
For logon via the network, the password is conveyed via multiple-encrypted transmission. Single encryption would allow the password to be intercepted and reused and is also a rather
is a cryptographic fingerprint that unmistakably identifies a character string or file. It is
With the Active Directory came a much more powerful remote logon method: Kerberos . Kerberos is based on Internet RFC 1510, with the corresponding Kerberos service (Kdcsvc.dll) executed on a domain controller under Windows 2000 Server or Windows Server 2003. Kerberos uses TCP/IP port 88 for communication between clients and domain controller.
Kerberos is based on what is commonly called the
. A ticket master on a domain controller issues a
After the user is authenticated, the local system verifies the user s access permission with the help of local policies. If the user does not have the necessary permissions for interactive logon, the process is aborted and a corresponding system message is displayed. If access is granted, the Lsass process adds all necessary security information and privileges to the user s access ID.
This is the point at which the user session is created (this is also true for local logon). In the registry, the Winlogon process reads the value from the HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\Userinit key and starts all programs enumerated in this character string. The character string usually contains several executable files that are separated by commas. One of the default programs is Userinit.exe. This program deals with loading the user profile and generating the process that is located in HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\Shell. In a standard environment, this would be Explorer.exe.
In terminal server environments, the value in the Shell key can be modified to prevent users from having full access to the desktop. This can apply to both clients and terminal servers. An alternative to Explorer.exe could, for instance, be Iexplore.exe. In this case, Internet Explorer would start instead of the regular desktop and all applications would need to be launched from a specially prepared HTML page.
However, there is one basic problem concerning all authentication procedures when using a terminal server. The user does not sit at the server hardware console and use the applications there; the applications are accessed through a Terminal Services client. The communication between client and terminal server always harbors a potential security risk. Communication does not
If, after successful authentication, the user wants to access an object ”that is, a file, a directory, an application, and so on ”the security subsystem requests the user s access token, verifies the relevant values, and
In addition to the primary Windows Server 2003 logon methods described so far, there is another option of logging on to a remote system via the network. In contrast to terminal server sessions, secondary logon does not have the purpose of working interactively with the remote computer. Instead, this secondary logon usually serves to access shared resources of a remote server. If both computers involved are in the same domain and the network is accessed within the context of a domain user, logon takes place in the background, invisible to the user. Further access is
Smart cards are
The software components of an RDP client are able to transmit the information on a smart card to a terminal server for logon. This requires the client and the security policies to allow smart card information to be redirected to the terminal server.