How does the SyncedDomainName configuration in MetaFrame XP FR2 help authentication with the Novell client?
(Last modified: 22Sep2003)
This document (10073209) is provided subject to the disclaimer at the end of this document.
fact
Citrix MetaFrame XP Feature Release 2 (FR2)
goal
How does the SyncedDomainName configuration in MetaFrame XP FR2 help authentication with the Novell client?
fact
Microsoft Windows 2000 Server with Terminal Services
Microsoft Windows NT 4.0 Server Terminal Server Edition (TSE)
Novell Client for Windows NT/2000/XP
symptom
Message: "Windows Security Message: A domain controller could not be found for the specified domain."
fix
The Citrix MetaFrame XP Feature Release 1 (FR1) and MetaFrame XP Feature Release 2 (FR2) products implement NDS integration features that allow ICA terminal clients to authenticate their terminal sessions using NDS credentials, and for MetaFrame XP application assignments and permissions to be granted based on NDS user information. The complete use and implementation of these features is beyond the scope of this document; refer to the MetaFrame XP FR1 and FR2 readme and administration documents available from Citrix at www.citrix.com.
Note that throughout this document the concept of "Windows domain" simply refers to the entity by which the Windows user accounts are identified. The name identified in the "Windows domain" field on a Windows login dialog may be an actual Windows domain name, or may just be the name of the Windows server (if the server is just a stand-alone workgroup server with no domain membership involved). The term "Windows domain" will be used universally throughout this discussion, with the understanding this could be either an actual Windows domain name or just the name of the Windows server where user accounts exist.
As part of allowing ICA terminal clients to authenticate using NDS credentials, current Citrix ICA clients will in technically pass an NDS user specification and the NDS tree name through fields that are normally the Windows username and Windows domain name. This is necessary because some of the defined Windows APIs and protocols MetaFrame is using do not provide for passing NDS credentials in addition to the Windows credentials. Therefore the NDS credentials were sent through the existing Windows credential fields.
For an older ICA client, Citrix documents "To use NDS logon information with earlier versions of ICA Win32 Clients, enter the NDS tree name in the Domain field and a distinguished name in the User field on the ICA Win32 Client logon screen." (Taken from the ICA32 6.30.1050 "Citrix ICA Win32 Clients Administrator's Guide", under "Novell Directory Services Support" on page 117.)
The situation this sets up is that the GINA being used on the MetaFrame server queries Windows for what are expected to be the Windows username, password and Windows domain name passed by the terminal client. The GINA will logically populate it's Windows credential fields with this information, not knowing that in reality the information received was actually an NDS tree name and NDS user object specification.
In MetaFrame XP FR1, the intended way (and only way) for this approach to work is by having a Novell Client for Windows NT/2000/XP client installed at the MetaFrame XP server, to have the TSClientAutoAdminLogon feature of the Novell client enabled, and then finally to have a Novell ZENworks for Desktops Dynamic Local User (DLU) applied to the NDS user that will be logging in via the terminal session. The requirements and configuration of the NDS integration feature are discussed more definitively in the "Novell Directory Services Integration" section of Advanced Concepts for MetaFrame XP with Feature Release 1 (Service Pack 1) available at www.citrix.com.
Enabling the TSClientAutoAdminLogon feature of the Novell client is actually handled by the Citrix Management Console (CMC) when you enable the NDS integration feature on a MetaFrame XP FR1 or later farm. (Specifying a "Novell Directory Services Preferred Tree" in the farm properties within the CMC enables the NDS integration features.) When this feature is enabled, the CMC will also establish a TSClientAutoAdminLogon configuration for the Novell client installed on the MetaFrame XP server.
The ZENworks for Desktops Dynamic Local User (DLU) policy is required in the MetaFrame XP FR1 implementation because the Windows username & Windows domain name fields are being used to pass the NDS user specification and NDS tree name from the ICA terminal client. Because this NDS information shows up in the fields that are normally used for the Windows username and Windows domain name on the login dialog, the login would fail if the information were actually used as though they were valid Windows credentials.
But because having a DLU policy causes any information present on the "Windows" tab of the Novell login dialog to be irrelevant (because the DLU policy defines exactly which Windows user account will be used, and any conflicting information on the Windows tab of the login dialog is simply ignored), having the DLU policy associated to the NDS user allows for a successful transparent login even though an "invalid" Windows username and Windows domain were passed from the ICA client.
If transparent login is attempted by passing NDS credentials from the ICA terminal client but without having the ZENworks DLU policy effective for the NDS user, the transparent login will fail with the following message:
[Windows Security Message]
A domain controller could not be found for the specified domain.
This is because the GINA is trying to use the specified Windows username and Windows domain information as-is, but this fails because the Windows domain field actually contains the name of the NDS tree, and no domain controller or Windows server by that name could be found.
In MetaFrame XP FR2, Citrix introduced the optional "SyncedDomainName" configuration parameter. This configuration parameter is described in the following document:
CTX737605, Integrating Novell NDS with NT domains using MetaFrame XP FR2 (Feature Release 2)
The "SyncedDomainName" configuration parameter defines the name of a Windows domain that will be passed to the GINA in the Windows domain name field in place of the NDS tree name received in the credentials from the ICA terminal client. Instead of passing on the Windows domain name field to the GINA as-is (which would be an invalid Windows domain name, since the field actually contains the NDS tree name), the domain named in the "SyncedDomainName" configuration parameter is passed to the GINA instead.
The situation this sets up is that Novell's NWGINA.DLL can actually come up with a valid set of Windows credentials once at least a correct Windows domain name is known. If a Windows user account already exists in the Windows domain with the same user name and password as the NDS user, NWGINA.DLL can successfully perform a TSClientAutoAdminLogon process using the credential information passed from the ICA terminal client, the Windows domain name MetaFrame XP substituted from the "SyncedDomainName" configuration parameter, and information from the default Novell client location profile (which is specified when setting up the TSClientAutoAdminLogon configuration).
So instead of absolutely requiring that a ZENworks DLU policy be present (as was the case with the MetaFrame XP FR1 implementation), by using the "SyncedDomainName" configuration parameter it is possible to transparently login as an NDS user and Windows user account that already exist and have the same user name and password assigned. (In other words, the NDS and Windows user accounts are already in sync.) You can still use a ZENworks DLU policy instead of the "SyncedDomainName" configuration; MetaFrame XP FR2 just provides the "SyncedDomainName" behavior as an additional option to leverage depending on which approach best fits the customer's environment.
Note also that the Windows domain named by the MetaFrame XP FR2 "SyncedDomainName" configuration parameter will be substituted ONLY if the NDS tree name passed from the ICA terminal client matches the NDS tree name configured as the "Novell Directory Services Preferred Tree" in the MetaFrame XP FR1 or FR2 farm properties. If the NDS tree name being passed by the ICA terminal client is different from the "Novell Directory Services Preferred Tree", the NDS tree name will be passed as-is in the Windows domain name field just as in FR1.
This brings up an additional point: If the NDS tree name passed from the ICA terminal client is longer than a "normal" Windows domain name (15 characters), the information contained in the Windows domain name field will be truncated & concatenated with the user's password. As such, even if the NDS user name being passed from the ICA terminal client IS supposed to match the "Novell Directory Services Preferred Tree" setting in the MetaFrame XP FR1 or FR2 farm properties, if the NDS tree name is longer than 15 characters it will fail to match because of the truncation & concatenation that is occurring. The issue of fields that get truncated when the NDS information being passed through them is longer than the expected Windows information is discussed further in:
Finally, one point that hasn't been covered yet but is central to both the MetaFrame XP FR1 and MetaFrame XP FR2 approaches is the "common name parsing" that the Novell NWGINA.DLL will apply to the information passed in the Windows username field. When the ICA terminal client passes the NDS user name specification through the Windows username field, it is in a format similar to ".CN=username.OU=orgunit.O=org" or ".username.orgunit.org". The "common name parsing" functionality identifies just the "username" portion of the string received and uses only that portion as the Windows username. The NDS login will use the entire string, allowing an NDS user object in any context to be passed in the NDS user name specification.
If the "common name parsing" is turned off (using the "DisableCommonNameParse" configuration parameter of the Novell client), the TSClientAutoAdminLogon process using the credentials from the ICA terminal client will fail because the login will be attempting to use a Windows username of ".CN=username.OU=orgunit.O=org" instead of just "username". The "DisableCommonNameParse" functionality is discussed in the following document:
.
document
| Document Title: | How does the SyncedDomainName configuration in MetaFrame XP FR2 help authentication with the Novell client? |
| Document ID: | 10073209 |
| Solution ID: | NOVL81453 |
| Creation Date: | 01Aug2002 |
| Modified Date: | 22Sep2003 |
| Novell Product Class: | NetWare |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.