User Account Security

Addressing security from a user perspective focuses on:

• The user account configuration.

• Secure user authentication

• The domain configuration and trust relationships.

User Account Configuration

You can configure several security options at the user layer. The advantage to configuring security at this layer is that the settings follow the user no matter where he logs on. In both Windows NT 4.0 and Active Directory environments, there are several user properties that affect the security of your Terminal Server environment. These user account configuration options can be broken down into three broad categories:

• Options that are configured as part of the user's domain account.

• Options that are configured per user or group as part of a server's local security rights.

• Options that are configured as part of a policy.

User Domain Account Configuration

The security options that are configured as part of a user's account properties are literally properties of the user account itself. In Windows NT 4.0, these properties are configured via user manager for domains and the configured options become part of a user's account in the SAM. In Active Directory, they are configured as part of a user's Active Directory account properties and the options become part of that user's Active Directory user object.

There are only a few user account properties specific to Terminal Services environments. (See the feature chart in the Appendix for a full list of settings that can be configured here.) First, each domain user that will use any Terminal Server must have the "Allow logon to Terminal Services" box checked in her account properties. If you have particular users that you do not want to use any Terminal Servers, uncheck this box. Unchecking this box results in the error "Your interactive logon privilege has been disabled" whenever the user attempts to log on to a Terminal Server.

In addition to this user right, the user must be a member of the Remote Desktop User's group on the Terminal Server itself or be a member of a domain group that is nested into this local group.

Each user's account also has properties similar to those that you can configure at the connection layer. These properties include timeouts for ending disconnected sessions, active and idle session limits, and whether the user can reconnect to disconnected sessions from any client or only from the original client. The settings apply to the user whether they connect to a Terminal Session via RDP or any other third-party protocol.

Not immediately obvious is how the "run program on startup" options work within a user's account properties. This option is similar to the initial program option that you can specify at the connection layer because when the user exits from the program, his Terminal Services session is ended. However, be aware that any initial program that you specify in a user's domain account property only affects him when he logs on to Terminal Services with the RDP protocol.

Server Local Security Rights

Each server can have a local policy in place that affects users' local security rights. These rights are configured via the local security policy of the server (Start | Administrative Tools | Local Security Settings | Security Settings | User Rights Assignments). You can configure local or domain users or groups with various user rights. While many user rights are not relevant to the security of Terminal Server environments, there are several that are. Some of the security-related rights include a user's ability to shut down the computer, change the system time, manage the auditing and security log, and take ownership of files. Again, the feature chart in the Appendix of this book shows which options can be configured here.

One of the security rights particularly useful in Terminal Server environments is the "log on locally" right. In order for a user to be able to use a Terminal Server, he must have the rights to log on locally to the server. In the real world, you might have 10 or 12 servers for 2 or 3 different departments. You can create a global group for each department, called "Dept A TS Users." Then, on the Terminal Servers that serve applications for Department A, you can remove the "log on locally" right from "Domain Users" and grant it to "Dept A TS Users."

Alternately, you can use the local group "Remote Desktop Users" and place your departmental users into this group since it is already assigned the "log on locally" right. Configuring the local security rights of the server gives you an extra level of protection beyond your NTFS security and Application Restriction policies.

In addition to the "log on locally" security right, you'll notice there is a "deny log on locally" security right. You might be confused as to why there are two of these and how each should be used. Normally, if you have users that you do not want to use Terminal Services, you can just choose not to give them the "log on locally" security right. That way, if the user is a member of multiple groups, they can get the "log on locally" security rights from any one of their group memberships. However, if you have specific users or groups that you definitely do not want to use the Terminal Server no matter what, then you can add them to the "deny log on locally" list. This security right will always take precedence if a user is on the list for both "log on locally" and "deny log on locally." Use the "deny log on locally" carefully because it is possible that one user might be a member of multiple groups with conflicting rights.

User Policies

All of the local security rights from the previous section can be deployed across multiple servers as part of a group policy. They are tied to specific user accounts only when those user accounts are added to the system policy or to an organizational unit where the group policy is applied. For detailed information regarding the use of policies in a Terminal Server environment, refer to Chapter 6. In all cases, domain policy or group policy settings will take precedence over the configured local security rights.

Secure User Authentication

One way that many organizations are securing their user environments is by implementing secure user authentication mechanisms. The three most popular methods are smart cards, two-factor authentication, and biometric authentication.

Smart Cards

In environments in which positive user identification is important, smart card technology if often used to authenticate users. Windows Server 2003 allows you to log on to a Terminal Server session in an Active Directory domain using a smart card. Smart cards allow you to require strong credentials from users, thus providing a more secure environment.

Smart cards offer several benefits:

• Secure credentials: Smart cards maintain credentials and private keys stored locally on the card. Furthermore, they provide tamper-resistant storage for that data. If a smart card is lost or stolen, it is almost impossible for anyone except the intended user to use the credentials that it stores. (Most smart cards have a "self destruct" feature that disables the card if the wrong PIN is entered a number of times in a row.)

• Isolation of sensitive data: Cryptographic operations are performed on the smart card itself rather instead of on the client or server. This feature isolates security-sensitive data and processes from other parts of the system.

• Portable security. Credentials and other private information stored on smart cards can easily be transported between computers at work, home, or other remote locations.

While smart card authentication is more secure than standard Windows authentication, you'll need to implement several things to use them in a Terminal Services environment. First, you'll need a public key infrastructure (PKI) before you can deploy smart cards in your organization. This can be a project in itself and can be expensive depending on the solution used. Next, you must have Active Directory deployed in your organization and your client computers must be running a client operating system with built-in smart card support, such as Windows XP or Windows 2000, and some versions of Windows CE .NET. Finally, you'll need to install smart card readers on the client computers.

In order for a user to log on to a Terminal Server, she inserts her smart card into the card reader. Her smart card contains a digital certificate which is transmitted to the Terminal Server. The server (which has its own X.509 digital certificate) checks the user's certificate from the smart card to verify that it matches the certificate on file. If so, the user is authenticated and her RDP session is launched.

For added security, policy options are usually configured on the Terminal Servers that dictate the action taken when the smart card is removed from the reader. Many companies configure their environments so that a user's session is immediately disconnected if her smart card is removed from the card reader attached to the client device.

Advantages of using Smart Cards

• Excellent two-factor security.

• Easy for users to use and understand.

Disadvantages of using Smart Cards

• Requires Windows 2000 or XP clients.

• Requires substantial smart card infrastructure (cards, readers, certificates, etc.).

• Users must remember to bring their smart cards with them.

• Users can lose their smart cards.

Before you begin using smartcards in your Terminal Server environment, you should have them working in your existing environment. You should have individual cards with users' certificates and PINs on them. Your backend directory (such as AD) should be ready to go. Your certificate authorities and digital certificates should be all set up. Once all this is in place, smart card usage with Terminal Server is easy to implement.

Token-Based Two-Factor Authentication Mechanisms

Since Terminal Server is based on standard Windows and Active Directory components, you can easily integrate third-party two-factor authentication. The most popular two-factor authentication products are Secure Computing's SafeWord PremierAccess (www.securecomputing.com) and RSA's SecurID (www.rsa.com).

Both of these companies offer keychain-sized electronic tokens that you distribute to your users. When a user attempts to log on to a Terminal Server, he needs his username, password, and the constantly-changing code from his token.

Two-factor authentication lowers the risk that stolen user credentials will lead to a breach of your system.

Advantages of using Token Authentication

• Excellent two-factor security.

• Easy for users to use and understand.

• You don't have to install any kind of hardware on the client devices.

• All types of platforms of client devices are supported.

• Tokens are cheap.

Disadvantages of using Token Authentication

• Users must remember to bring their tokens with them.

• Users can lose their tokens.

• Tokens take batteries

Biometric Authentication

If two-factor authentication does not provide enough security for you, you can also use biometric authentication for your Terminal Servers. The term "biometric authentication" conjures up all sorts of mental pictures, but in today's world it usually means fingerprint scanners. There are dozens of companies that make these scanners, and you can now get them at any electronics store for under $100.

The problem with most fingerprint scanners is that they come with software that installs on a local workstation and memorizes your fingerprint and your passwords. It then "stuffs" your passwords into login boxes that appear on your workstation. While this is a great solution for individual users, it doesn't do much good in enterprise Terminal Server environments.

Fortunately, you can buy enterprise software that can pull together these random fingerprint scanners. One of the most popular is SAFsolution from SAFlink (www.saflink.com). This software incorporates biometric authentication into your Active Directory while letting your users choose any standards-compliant biometric device that they want. For example, if you use Terminal Server to provide applications to remote customers, you can tell them that they need a fingerprint scanner but that they can buy whichever one you want. You can then use the SAFlink software to ensure that they cannot authenticate to your Active Directory unless they have a fingerprint scanner installed.

Advantages of using Biometric Authentication

• Attackers cannot impersonate users' accounts.

• User does not have to remember to bring his smart card or token with him.

• There's nothing for the user to lose.

Disadvantages of using Biometric Authentication

• You must purchase biometric devices for each client.

• You must purchase enterprise biometric software to run everything.

• Some cheap fingerprint scanners can be fooled by photocopies and gelatin molds.