The last layer of security that we need to look at is the security and configuration of the user accounts themselves. When addressing security from a user perspective, there are three different items that must be addressed:
- 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 Windows 2000, there are several user properties that affect the security of your MetaFrame XP environment. These user-layer security 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 Windows 2000, 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 MetaFrame XP (or any Terminal Services) environments. First, each domain user that will use any MetaFrame XP server must have the "Allow logon to Terminal Services" box checked in their account properties. If you have particular users that you do not want to use any MetaFrame XP servers, you can uncheck this box. Unchecking this box affects the user for both RDP and ICA connections.
Each user's account also has properties similar to those that you can configure at the connection layer. These properties include the timeouts for ending disconnected sessions, active and idle session limits, and whether the user can reconnect to disconnected sessions from any client or only the original client. These settings apply to the user whether they connect via RDP or ICA.
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, their 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 onto Terminal Services with the RDP protocol. MetaFrame XP ICA connections are unaffected.
Server Local Security Rights
Each server can have a local policy in place that affects users' local security rights. The way you configure these local user rights depends on the platform on which your MetaFrame XP servers are running. In Windows NT 4.0, user rights are configured via user manager on the target server (user manager | policies menu | user rights). In Windows 2000, local user rights are set via the local security policy of a server (administrative tools | local security settings | security settings | user rights assignments). On both platforms, you can configure local or domain users or groups with various user rights. While many of these user rights are not relevant to the security of MetaFrame XP 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.
One of these security rights that is particularly useful in MetaFrame XP environments is the "log on locally" right (log on interactively in Windows NT 4.0). In order for a user to be able to use a MetaFrame XP 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 Citrix Users." Then, on the MetaFrame XP servers that serve applications to Department A, you can remove the "log on locally" right from "Domain Users" and grant it to "Dept A Citrix Users." Configuring the local security rights of the server gives you an extra level of protection beyond your published application and NTFS security. If you do this, remember also to grant "log on locally rights" to the group that contains the MetaFrame XP administrators.
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 they 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 MetaFrame XP 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." You need to use the "deny log on locally" carefully because it is possible that one user might be a member of multiple groups and each group could have conflicting rights.
All of the local security rights from the previous section can be deployed across multiple servers as part of a domain policy (NT 4) or group policy (Windows 2000). 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 MetaFrame XP environment, refer to Chapter 7. 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. There are two methods that work well in MetaFrame XP environments:
- Smart cards.
- RSA SecurID hardware tokens.
In environments in which positive user identification is important, smart card technology if often used to authenticate users.
In MetaFrame XP environments, smart card readers can be attached directly to ICA client devices. In order for a user to logon to run their ICA applications, they insert their smart card into the card reader. Their smart card contains a digital certificate which is transmitted to the MetaFrame XP 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 their MetaFrame session is launched.
For added security, policy options are usually configured on the MetaFrame XP 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 their smart card is removed from the card reader attached to the client device.
Using smart cards in MetaFrame XP environments is no more difficult than using them in standard Windows 2000 environments. Getting your existing Windows servers, clients, and Active Directory configured for smart cards represents the bulk of your work. Extending MetaFrame XP to work with smart cards is the easy part.
This section is not intended to teach you everything there is to know about using smart cards in Windows. That would require an additional 800 pages. The purpose of rather is to provide information about how existing smart card implementations can be extended with MetaFrame XP. For more information about smart card usage in Windows 2000 environments, check out Microsoft article Q313274. This article describes the process to configure a Windows 2000 certificate authority to issue smart card certificates. It also contains links to other Microsoft articles that step through the process of getting a background smart card environment set up.
To secure your MetaFrame XP environments with smart cards, you need to use Feature Release 2. Also, your client devices must use the 32-bit Windows or Java ICA client, version 6.30 or newer.
Windows 2000 and Windows XP are the only Microsoft operating systems that directly support smart cards. However, so long as your MetaFrame XP server is running Windows 2000, you can use smart cards from any 32-bit Windows client, including Windows 9x.
This is possible because the ICA protocol has been extended with Feature Release 2 and version 6.30 clients. A smart card channel has been added that passes smart card information from client devices to the MetaFrame XP server.
Therefore, if your clients are using Windows 9x, a locally attached smart card reader cannot prevent a user from logging on locally to the client desktop. However, they can be prevented from logging on to MetaFrame XP without proper smart card authentication.
If your ICA clients are running Windows 2000 or Windows XP, the smart card software and drivers can be installed locally on them to enforce local logons. In this situation, the smart card reader would be used for local logon and remote MetaFrame XP logon.
Advantages of using Smart Cards
- Ultimate security.
- Easy for users to use and understand.
Disadvantages of using Smart Cards
- Requires Feature Release 2.
- Requires the Citrix ICA Win32 or Java client.
- Requires substantial smart card infrastructure (cards, readers, certificates, etc.).
Before you begin using smartcards in your MetaFrame XP environment, you should have them working in your existing environment. This means that you should have individual cards with user's 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 MetaFrame XP is very straightforward.
RSA SecurID Hardware Tokens
If you use RSA SecurID hardware tokens in your environment for two-factor authentication, you can easily extend their use to NFuse 1.7 Classic environments. Out of the box, your users must access a web page to authenticate with their token (against an RSA "ACE" server). Then, users must access a second web page where they enter their credentials to authenticate to NFuse.
However, you can use "Project Willamette" to consolidate these authentication pages so that your users' standard NFuse login page asks for their username, password, and SecurID token passcode. Project William is written by some very smart people from a company called ISC (www.iscnet.co.uk). You can download Project Willamette for free from www.tweakcitrix.com/sections/ wilakenz.htm. In order to use Project Willamette with NFuse 1.7, download Project Willamette version 2.0 or newer.
Project Willamette only has a few requirements:
- Your NFuse web server must be running on a Microsoft Windows 2000 Server with Service Pack 2 or newer.
- You must be using IIS as your web server.
- You must have an X.509 digital certificate for your NFuse web server.
- The RSA ACE Agent for Windows v5.0x or newer must be installed on your NFuse web server.
- You need to use Citrix Secure Gateway with a Secure Ticket Authority.
- Your users' SecurID usernames (their "ACE" accounts) need to match the usernames of their domain accounts.
Using Project Willamette is simple. It basically includes modified NFuse web pages, and all you have to do to use it is to copy a few files from Project Willamette over the original files on your NFuse web server.
Advantages of Project Willamette
- Easy to install and configure.
- Simplifies and clarifies the user login process.
- It's free (thanks to Chris Walsh and Martin Hodgson).
Disadvantages of Project Willamette
MetaFrame XP server farms are extremely flexible. This flexibility allows one server farm to span multiple domains or forests. However, just because a server farm can technically span multiple domains or forests, extreme caution must be exercised with this option. There can be conflicts with user credentials and permissions. Consider the following scenario.
The Burning Troll Lumber Company has two Windows 2000 domains, EAST and WEST. Each domain has a domain local group (DLG) for users: EAST-USERS and WEST-USERS. By definition, a DLG cannot contain members of other domains. (Hence the "L" in "DLG.")
Figure 15.23: Burning Troll Lumber's Windows 2000 domains
The Burning Troll Lumber Company has one MetaFrame XP server farm for their entire enterprise with servers in both the EAST and the WEST domains. They have one published application, "LumberTracker," which they load-balanced on all MetaFrame XP servers. They want to publish the application explicitly to both the EAST-USERS and WEST-USERS groups.
As you may have figured out, this configuration will cause a problem. Consider how load-balanced published applications work. A user requests the application-LumberTracker in this case. The MetaFrame XP back-end determines which server is least busy and returns that server address to the user. For the Burning Troll Lumber Company, this could cause a technical short-circuit. What if a user from the west is given the address for a server in the east? Because the WEST-USERS group is a domain local group, the east servers do not recognize it. The server would not allow the user to start a session.
The Burning Troll Lumber Scenario could never happen in the real world. There are two ways that MetaFrame XP automatically addresses this situation to prevent it from occurring:
- Trust Intersections. MetaFrame XP does not allow the permissions of the published applications to be set unless all target users and groups can access the application on all servers where it is published.
- Trust-Based Routing. MetaFrame XP will dynamically route authentication to a server on which the user has permissions.
When setting the permissions of an explicit application via the CMC, MetaFrame XP only shows users and groups that have permission to access the application on all the servers where the published application is configured. If you try to be crafty by setting the permissions first and then going back and adding servers where those permissions would not be valid, MetaFrame XP produces an error message and automatically removes the users or groups that cannot access the application on every server where it is published.
Even though you cannot configure applications to be published to users that don't have rights on all the servers where the application is published, it's still possible that a user could do something that would require him to be authenticated by a server where he doesn't have rights. If this happens, the user's authentication is transparently passed on to another farm server where the user does have access. This is known as "trust-based routing." It's possible because MetaFrame XP keeps track of Windows domain trust relationships via the IMA data store. The domains and associated trust relationships of all farm servers are updated during a trust query cycle. A trust query cycle occurs when the IMA service starts and every six hours thereafter.
Trust based routing can occur in the following situations:
- A user refreshes the application list or launches a published application.
- An administrator launches the CMC.
- Anytime accounts are listed in the CMC, including adding users or groups to applications, printer auto-creation, and adding farm administrators.
Looking back to the lumber example, if a farm administrator from the WEST domain tried to use the CMC to connect to a server in the EAST domain, the server from the east would route the authentication to a server in the WEST. This routing would be necessary because the server in the east would recognize that the administrator has farm administrator rights, but would not be able to authenticate the user because the user account is in a different domain.
How to Mitigate Domain Trust Issues
If you decide that trust intersections and trust based routing is too risky or confusing, you can follow these guidelines to avoid having MetaFrame XP invoke its trust voodoo. Think of these as the three golden rules of server farm design if you don't want to troubleshoot weird trust problems:
- Do not publish applications across servers in different domains to domain local groups.
- Do not publish applications across servers in different forests to domain local groups.
- Do not publish applications across servers in different non-trusted domains in Windows NT 4.
To summarize, you should really make sure that all of your farm administrators have administrative rights on all your MetaFrame XP servers and that all of your users have rights on any servers that they would ever access. Remember that MetaFrame XP server farms operate totally independently of domain boundaries, so using some sense when you design your farms will save you from headaches down the road. The simplest way to avoid all this is to not create server farms that include servers from multiple non-trusted domains.