As you learned earlier in this chapter, one of the traditional challenges of integrating MetaFrame XP environments with NetWare environments has been that the ICA clients were only capable of passing the three Windows authentication parameters (username, password, and domain) to launch an ICA session. Citrix began to address this problem with the version 6.20 release of their ICA client software. This software is able to pass full NDS credentials to a MetaFrame XP server in place of Windows credentials.
The ability to do this makes it a lot easier for NDS users to use your servers. From the user standpoint, they can enter their credentials directly into the ICA client software or the NFuse web page. Once their ICA sessions are launched, they do not have to worry about retyping their credentials. The logon and authentication process is as seamless as it is in any full-Microsoft environment.
Requirements for Using MetaFrame XP's NDS Features
In order to use NDS integration with ICA clients, there are several requirements that must be met, as outlined in the following list. This list represents the minimum requirements. For each of these items, newer versions are also acceptable:
- Feature Release Level. You need to have at least Feature Release 1installed on each MetaFrame XP server that you want to make available to NDS users.
- NDS 8.73 or eDirectory 8.5. NDS 8.73 is only supported on NetWare 5. eDirectory can run on multiple platforms, including Windows 2000 Server.
- ZENworks for Desktops 3. MetaFrame XP's NDS integration leverages ZENwork's "Dynamic Local User" technology. (More on this later.)
- Novell NDS Client version 4.8. This software must be installed on each MetaFrame XP server that you want to make available to NDS users.
- ICA Client Software 6.20. This is needed on each ICA client device that you want to integrate with MetaFrame XP's NDS features.
- A Single NDS tree. The NDS tree that MetaFrame XP server users log in to is configured at the server farm level. If you have more than one tree that you need to log in to, then you will need to connect to each tree from separate server farms.
- Dedicated MetaFrame XP Servers. If you configure MetaFrame XP servers to authenticate users via NDS, then they cannot authenticate users via Microsoft domains. You will have to choose which servers use Windows authentication, and which use NetWare authentication.
If you've met all of these requirements, then you can use MetaFrame XP's NDS integration features. If you don't meet them, then you'll need to use one of the other methods of integrating your NetWare users with your MetaFrame XP servers.
Advantages of FR-1 or FR-2 NDS Integration
- Users can log on with their existing NDS credentials.
- No need to duplicate user accounts between your Windows and NDS environments.
- Tight integration with MetaFrame XP features, including application publishing, NFuse 1.6 and 1.7 Classic, pass-through authentication, connection control, printer management, and Program Neighborhood.
Disadvantages of FR-1 or FR-2 NDS Integration
- Only one NDS tree can be supported per server farm.
- ZENworks is required.
- A single MetaFrame XP server can only be configured to support Windows users or NDS users-not both.
- You must manage the NDS components or your MetaFrame XP environment while logged onto the CMC as an NDS user.
- NDPS print queues are not directly supported, although this can be configured via ZENworks.
- Feature Release 1 or newer is required.
Configuration of NDS Integration with Feature Release 1 or 2
If you decide that you would like to use the NDS integration features of MetaFrame XP, you can use the following process to configure everything. This process assumes that Feature Release 1 or 2 is enabled on the MetaFrame XP servers that you're using:
- Enable the Dynamic Local User policy in ZENworks for Desktops. This allows your users to logon to your MetaFrame XP servers without explicitly-configured local Windows accounts. To do this, ZENworks uses a "Dynamic Local User" account (DLU). Basically, when a user needs to log onto a MetaFrame XP server, ZENworks uses its own domain administrator rights to create a new local user account on the MetaFrame XP server. ZENworks builds the user's custom desktop as needed from their NDS profile. When the user logs off, the account is deleted. This entire process is transparent to the end user. From their standpoint, they logged onto the server by only using their NDS account.
- Install the Novell NDS Client software, version 4.8 or newer. Refer to the process outlined in the "Configuration of Novell NDS Client" section earlier in this chapter.
- Enable NDS support in the server farm. Connect to a MetaFrame XP server that has Feature Release 1 or 2 enabled and the Novell client installed. Enable NDS support by adding the NDS tree name in the CMC (CMC | Right-click on Farm | Properties | MetaFrame Settings Tab | NDS Preferred Tree). When you do this, the "TSClientAutoAdminLogon" registry key will automatically be configured on all farm servers.
- Give at least one NDS account farm administrator rights (CMC | Right-click Citrix Administrators | Add a Citrix Administrator | Double-click NDS tree | Show Users | Select User | Add button). As with standard administrators, NDS administrators can be Read-Only or Read-Write. If you select an NDS object that has objects below it, then the child objects will have the same permissions.
- Open a CMC session as an NDS administrator. You do this by launching the CMC as normal, except that you enter NDS user credentials into the authentication box instead of Windows credentials. (If you're using Feature Release 2's pass-through authentication to launch the CMC, you'll need to logon to the server as the NDS user.) Because there are no extra fields for the NDS tree or context, you must log on with the full distinguished name. This is simply the full path to your user account in the NDS tree, with a leading period and periods between each object (.username.your-ou.organization). Of course you might have more than one OU in your distinguished name. Also, when logging into the CMC, you need to enter the NDS tree name in the domain field.
- Publish applications for NDS users that only NDS users will use. To do this, you publish the application or content as usual (CMC | Right-click Applications | New Application), except that you specify users from the NDS tree instead of a Windows domain. Again, any permissions that you set also apply to the child objects below the object for which you grant the permissions.
Once you complete these steps, your server farm will be fully integrated with NDS. For ICA client-specific configuration issues, see the ICA Clients chapter (Chapter 10). For NFuse-specific NDS configuration, see the NFuse chapter (Chapter 11).
Feature Release 2 Refinements to NDS Integration
For the most part, Feature Release 2 does not affect how Novell NDS integration works with MetaFrame XP servers. However, there is one slight change in FR-2 that can allow you to use Novell NDS integration without using the ZenWorks Dynamic Local User (DLU) policy. With Feature Release 1, the ZenWorks DLU is required because the when farm-wide NDS integration is enabled, the Windows username and domain fields are actually used to pass the NDS credentials from the ICA client. Since NDS credentials show up in the fields normally used for Windows credentials, the logon would fail if these credentials were simply passed to Windows.
However, since FR-1 uses ZenWorks DLUs, any information on the "Windows" tab of the Novell NDS Client login box is ignored since the Windows logon information is pulled from the ZenWorks DLU policy. This means that NDS users can successfully logon even with invalid credentials on the Windows tab.
With FR-1, if an NDS user tries to logon with NDS credentials from an ICA session when ZenWorks DLU is not used, the logon will fail because the credentials from the "Windows" tab are applied (since ZenWorks was not used to replace them). The system is trying to use the Windows username and domain information as-is, but those credentials fail because the domain field actually contains the name of the NDS tree (because the farm is in NDS mode).
With Feature Release 2, a new "SyncedDomainName" registry key is available to prevent this problem from occurring:
Registry Location: HKLM\SOFTWARE\Citrix
Key: NDS (You will need to create this key.)
Data: The name of your Windows domain
You can use this parameter to specify the name of a Windows domain that will be used to log the user on. This is needed because your farm is operating in NDS mode, meaning that the domain parameter from the user's ICA logon is interpreted as the NDS tree. By adding the "SyncedDomainName" value, a valid Windows domain will be available that the TSClientAutoAdminLogon can process to log the user on. The only disadvantage of this is that your usernames and passwords will need to be the same in NDS and Windows.
Advantages of the SyncedDomainName key
- You can use MetaFrame XP's "official" NDS integration without using ZenWorks' Dynamic Local User policies.
Disadvantages of the SyncedDomainName key
- Feature Release 2 is required.
- Users' Windows usernames and passwords must match their NDS usernames and passwords.
- This only works if your NDS tree name is less than 15 characters long (the limit for Windows domain names).
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.