Product Interoperability: Novell ZENworks for Desktops 4.x and Novell iChain

ZENworks for Desktops Management Agent and NetIdentity Agent not compatible.

ZENworks 4.x and iChain 2.3 Interoperability
Novell iChain 2.3 uses the NetIdentity client for proxy authentication. ZENworks for Desktops 4.0.1 Interim Release 4 adds cookie support and other enhancements and fixes that allow some interoperability between the two products.

User-associated NAL applications and policies work through iChain, although some exceptions exist and are detailed in this document as applicable. Workstation based features such as import and policies, Remote Control, Workstation Inventory, and others currently do not work through iChain 2.3. These interoperability issues will be addressed in a future ZENworks release.

Note that the Middle Tier Server software used in this interoperability testing was installed on NetWare 6 SP3 only.

Test Results with Accelerator Configuration

• iChain 2.3.240 (and later) and ZENworks for Desktops 4.0.1 Interim Release 4 (build 0317 and later) have been successfully tested together. Typical iChain configuration settings have been tested, including Alt Host Name, Secure Exchange, Secure Fill, Authentication using NetIdentity, and Realm names set the same and set differently.
  
• As of March 19, 2004, no testing has been done with domain-based multi-homing iChain configurations because of the number and complexity of issues discovered so far.
  
• Using the iChain path-based multi-homing feature for the ZENworks Middle Tier server accelerator results in an improper GET request being sent from the workstation. The accelerator’s sub-path match string is used as part of the DNS Name and results in a connection failure to iChain and the Middle Tier server.
  
• If Secure Exchange between iChain and the workstation is enabled on the accelerator for the Middle Tier Server, use only port 443 for SSL as specified in the MiddleTierAddress value in myapps.html and in the accelerator’s configuration. Also, be sure to enable accelerator option "Allow pages to be cached at the browser” or users will be unable to download the ZENworks for Desktops 4.x NAL Plug-in (that is, the Application Browser view of the Novell Application Launcher). For more information, see TID10075939.
  
• Secure Exchange between iChain and the Middle Tier server can be enabled or disabled as desired.

Using the ZENworks Management Agent to Access the Middle Tier through iChain

Among other things, the ZENworks Management Agent (installed from an .msi file) supports the Novell Application Launcher, policies, and Workstation Management. It provides a different GINA login dialog when booting the workstation, where the username and password can be provided for desktop and network login. The Agent installation program can also be configured to allow a user to specify the DNS name and port of the Middle Tier Server where he or she logs in.

If a user enters credentials in the GINA login dialog that are valid iChain and Middle Tier credentials, and if the server DNS Name and port resolve to an iChain accelerator for the Middle Tier Server, the user will be authenticated to iChain and to the Middle Tier Server with no further prompt for login when the Middle Tier connection is attempted. This occurs because the ZENworks Management Agent, by default, sends the user’s desktop credentials if challenged for authentication by a NetIdentity-aware application such as iChain or the ZENworks Middle Tier Server. If the desktop credentials do not provide a successful login, the user is prompted with the NetIdentity-style pop-up login dialog box.

Con.figure the iChain accelerator for the Middle Tier Server to use an LDAP Authentication profile that allows NetIdentity authentication and use a Realm name that matches the Realm name of the Middle Tier Server.

When you use SSL between the workstation and iChain (with Secure Exchange enabled), the workstation must trust the CA used to sign the accelerator’s SSL certificate. This root certificate must be placed in the workstation store (not the user store) of the browser. Details are provided below regarding how to import the Trusted Root to the workstation store. Also, ZENworks for Desktops requires that only port 443 be used for SSL between the workstation and iChain, and the workstation must specify port 443 in the GINA’s "Middle Tier:” field (the iChain redirect from HTTP to HTTPS that occurs when using a browser does not work with ZENworks for Desktops workstation components).

After being authenticated to the Middle Tier Server through iChain, the user has access to NAL applications through normal methods such as the Application Window, NAL cache, and User Policies (including DLU, Group and Extensible policies). Workstation Import, Workstation Inventory, and Remote Management do not work through iChain.

Using the NAL Application Browser View to access the Middle Tier Server through iChain (NAL only, policies and other features such as AWI, Inventory, RM etc. are not available)

The NAL Application Browser View (also called the "NAL Plug-in”) provides access to NAL applications from a browser, but it does not provide access to other ZENworks for Desktops features such as policies, Remote Management. The NAL Application Browser View is downloaded (zfdinstallmgr.cab, netidentity.cab, and zfd40.cab) and installed when the user connects to the Middle Tier Server through the myapps.html URL. The Novell Client or the ZENworks Management Agent are not required on the workstation.

The URL for the Middle Tier Server follows the format of http(s):///myapps.html. Before users access the Middle Tier Server, you must edit as necessary the URL values for "MiddleTierAddress” and the codebase for"ZfdWebInstallerOcx” in apache/nwdocs/myapps.html on the Middle Tier Server. By default, these parameters are set to the Middle Tier Server’s local address and are hard-coded for HTTP on port 80. The values configured in myapps.html become registry settings at the workstation after installing the NAL Application Browser View. The URLs configured in myapps.html are critical and can be problematic, especially when accessing the Middle Tier Server through iChain. See below for more details.

Unlike the ZENworks Management Agent, which allows the user to set the values for the Middle Tier Server address and port, those using the NAL Plug-in can configure these settings at the workstation only by using regedit. Users that use one machine to access the Middle Tier Server from the intranet and internet using different DNS Names and ports have to edit the registry to set the MiddleTierServer and MiddleTierPort values to the appropriate values, depending on their location.

While the"codebase” value allows a scheme://DNSName:port to be specified (and thus is rewritable by iChain’s internal rewriter), the value for MiddleTierAddress does not work properly if a scheme (HTTP or HTTPS) is included. Only the DNSname and port can be specified. This causes problems for iChain’s internal rewriter because the value= tag that is sent to the workstation does not include the scheme, and so it will not be rewritten. The user will be able to authenticate to iChain and the Middle Tier Server, but the Novell Application Launcher will not function properly. More details on this issue are given below.

Known Issue

The value set in myapps.html for MiddleTierAddress and port that is subsequently set in the workstation registry i.s not rewritten by iChain. This results in a connection failure to the Middle Tier Server. The registry value for MiddleTierAddress is currently set to the internal scheme/servername/port of the Middle Tier Server instead of the scheme/DNSName/port of the accelerator. Myapps.html should allow a scheme to be included (http:// or https://) in the MiddleTierAddress value in order for the rewriter to update it to the public scheme/DNS name/port of the accelerator.

In the ZFD0401 Patch 0311 build, if a scheme is included, the rewriter makes the hostname change as expected (because the value= tag being sent from the Middle Tier includes the scheme) but the resulting workstation registry value in hklm/sw/novell/zenworks/MiddleTierAddress is simply set to "http” with no hostname or path. Spoke with a ZFD developer on this, he said he parses the value and assumes everything to the left of the first ":” is a hostname, everything to the right is a port value.

Possible workarounds:
1) Hard-code the accelerator’s public side DNS name and port in myapps.html for the MiddleTierAddress value. This may break internal users and could also be viewed as a security risk because the internal DNS name is exposed.

2) Don’t use an Alt Host Name and also use the same public side and Web server ports in the accelerator configuration.

3) After the workstationn installs the plug-in and accesses the ZENworks Middle Tier Server the first time, manually edit the workstation registry and set the correct values for HKLM/software/novell/Zenworks/MiddleTierAddress and MiddleTierPort to match the accelerator if accessing the MiddleTier through iChain.

4) Use Custom Rewriter to update the URL reference. Below is a sample custom rewriter configuration that allows iChain to modify the partial URL reference in the MiddleTierAddress value to match the accelerator’s public side configuration. Using this setup, workstations accessing the Middle Tier through iChain would have registry key HKLM/software/novell/Zenworks/MiddleTierAddress and MiddleTierPort values get set to the DNS Name and public port of the Middle Tier accelerator, while workstations directly accessing the Middle Tier would get the values as configured in myapps.html.

• On the iChain server, create file /etc/proxy/custom.cfg with the following contents:

[URL]
/*

[Extension]
html

[Replace]
:<<>>:

• where the value in [URL] is the DNS Name of the Middle Tier accelerator
• where [Replace] holds the original IP Address or DNS Name for MiddleTierAddress as configured in myapps.html and the accelerator DNS Name that rewrite.nlm will replace it with
  
• On the iChain server, load custom rewriter:
  
  load rewrite.nlm –s –f /etc/proxy/custom.cfg

Single Sign-on Considerations

The Middle Tier accelerator should use an LDAP authentication profile with option "Allow authentication through NetIdentity” enabled and the NetIdentity Realm name set to match the Realm name of the. Middle Tier Server. The Realm name is normally the eDirectory tree name where the Middle Tier Server is installed. This configuration allows SSO-type behavior if the user credentials for iChain and the Middle Tier are the same. This occurs because by default, the ZENworks for Desktops plug-in sends the user’s desktop login credentials to any NetIdentity-aware application (such as iChain and the Middle Tier). When the Middle Tier is accelerated by iChain, background authentication to proxy and the Middle Tier Server can occur if the desktop credentials are valid to both iChain and the Middle Tier. The ability to disable use of desktop login credentials is not available as a registry setting, but it can be disabled with a modification to the ProviderOrder registry setting. For more information, see Miscellaneous Considerations, below.

Another NetIdentity client registry setting, "Strict Trust,” is not enabled by default. You can set the Strict Trust value at HKLM/sw/Novell/Client/Policies/NetIdentity/Strict Trust.

Miscellaneous Considerations

• Windows 98 Extensible Policies do not work through iChain. This occurs when workstation components resulting in GET requests are sent with no Content-Length header.
  
• If Secure Exchange is enabled on the Middle Tier accelerator, use only port 443 as the "SSL Listening port” on the iChain accelerator and set the workstation’s "Middle Tier:” port to 443 (When using the Agent, the port number can be set in the GINA login dialog or using registry setting HKLM/SW/Novell /ZENworks/MiddleTierPort. For the plugins, the setting can only be changed in the registry). The HTTP to HTTPS iChain redirect that would normally occur when cthe onnection from a browser does not work with the ZENworks for Desktops workstation components and the connection will fail.
  
• For a GINA login to the Middle Tier Server through iChain, the workstation must trust the CA used for the iChain accelerator for the MiddleTier Server. The trusted root certificate must be installed in the Workstation’s certificate store, not the User store. To do this manually from a browser, browse using https to the iChain accelerator. Double-click the lock icon at the bottom of the browser window, go to page "Certification Path” and highlight the topmost object in the certificate chain. Click "View Certificate”, then click "Install Certificate”. When prompted for the"Certificate Store” location, select "Place all certificates in the following store”, then click Browse. Select "Show physical stores”, then expand the "Trusted Root Certification Authorities” folder. Select "Local Computer”, then click OK. Follow the prompts to Finish.
  
• Registry setting HKLM/SW/Novell/Client/Policies/NetIdentity/Strict Trust works as expected (same as in 1.2.1 NetIdentity client) but "Try Local Credentials” is not available as a registry setting with the ZENworks for Desktops 4.0.1 Agent or with the NAL Plug-in. Local credentials are always used for login attempts to Xtier-aware applications
  

One way to prevent use of local credentials, if absolutely necessary, is to remove the registry setting for ncredmgr.dll:

The registry setting on Windows 2000 is in

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder.

To prevent desktop login credentials from being attempted for NetIdentity authentications, edit ProviderOrder by removing NCredMgr from the value.