Troubleshooting authentication through the MiddleTier

  • 3668084
  • 18-Jan-2008
  • 30-Apr-2012


Novell ZENworks 7 Desktop Management Support Pack 1 - ZDM7 SP1 Middle Tier
Novell ZENworks for Desktops 4.0 - ZfD4
Novell ZENworks for Desktops 4.0 SP1b
Novell ZENworks for Desktops 4.0.1 - ZfD401
Novell ZENworks 6.5 Desktop Management - ZfD6.5
Novell ZENworks Management Agent
Novell ZENworks Middle Tier


Cannot authenticate to eDirectory via the ZENworks Management Agent
Cannot authenticate to eDirectory via the ZENworks NAL Agent
Cannot authenticate to eDirectory using /oneNet/xtier-login in IE.
Authentication to eDir thru middletier works if login to AD Domain is not included.
Troubleshooting authentication through the MiddleTier
Cannot authenticate due to incorrect GINA through MiddleTier


The following is a list of troubleshooting steps that should identify / resolve eDirectory authentication problems through the ZENworks Middle Tier:

  1. Ensure that the Web Server is running:
    NetWare 6- Type "m apache" at the system console and if nothing comes back, the Apache web server is not running. AUTOEXEC.NCF should launch NVXADMUP.NCF which will load Apache.

    NetWare 6.5- Type "m apache2" at the system console. Look for an APACHE2.NLM loaded from the OS address space (not the ADMINSRV address space). The AUTOEXEC.NCF should launch AP2WEBUP.NCF which will load Apache.

    Windows -Use the Internet Services Manager to see if the Default Web Site is running. Highlighting the server name will show the status of the Internet Services in the right hand window pane.

  2. Ensure theMiddleTierPortis correct:
    NetWare 6- look at the SYS:APACHE\CONF\ADMINSERV.CONF, the PORT line will tell you which port the Middle-Tier is going to listen on.

    NetWare 6.5- Look at the SYS:\APACHE2\CONF\HTTPD.CONF, the LISTEN line will tell you which port the Middle Tier is going to listen on.

    Windows- Check port of the Default Web Site in IIS, by going to the properties of the Default Web Site in the Internet Service Manager. The port is listed on the "Web Site" tab.

    Workstation- Make sure that the Desktop Management Agent has been installed with the same port that has been configured on the Middle Tier web server. If you have already installed the Desktop Management Agent, check the Network Identity applet (4x) or ZENworks Agent Options (6.5) in the Control Panel. It will list the Middle-Tier, and the port number should be listed after the ":". That setting is stored in the workstation's registry at HKLM\Software\Novell\ZENworks\MiddleTierPort.

  3. Ensure that the XTier components are configured and running correctly on the MiddleTier server:
    NetWare- Make sure you have an INCLUDE statement for XSRV.CONF inside of the ADMINSERV.CONF. Do a "m mod_xsrv" at the NetWare console to ensure that this NLM was loaded by Apache.

    NetWare 6.5- Make sure you have an INCLUDE statement for XSRV.CONF inside of the HTTPD.CONF. Do a "m mod_xsrv" at the NetWare console to ensure that this NLM was loaded by Apache.

    Windows- Check that the ISAPI filter of oneNet is showing in a color of green and is up. This is found on the ISAPI Filters tab of the Default Web Site properties in the Internet Service Manager. The Filter name is: oneNet, the Executable is: C:\WINDOWS\System32\InetSrv\XTIISFlt.dll. If the arrow pointing up is green, ensure that the onenet.dll has been registered. You can do this by unregistering it and re-registering it (regsvr32 c:\onenet\onenet.dll -u ; regsvr32 c:\onenet\onenet.dll and then reboot).

  4. Ensure the NCP client on the MidTier is loaded.
    NetWare -type m ncpl and if the NLM comes back with information about itself, then it is loaded. It should be started via the AUTOEXEC.NCF.

    Windows -check for the NCPLW32.DLL module (Run msinfo32.exe and look in Software Environment > Loaded Modules).

  5. Try a website that doesn't require authentication.
    For example, the oneNet/xtier-stats page does not require authentication (for an explanation of the statistics listed on this screen, seeTID 10091113). If this web page works, then we can assume the webserver is functional and that the middletier has been installed on this server.

    Windows -m ake sure that the IUSR_SERVERNAME user object has the following rights to the C:\oneNet directory: Read & Execute, List Folder Contents, Read, Special Permissions with Create Files / Write Data, Create Folders / Append Data.

  6. Ensure the authentication criteria defined during the install is correct.
    First, try hitting the NSADMIN page (case-sensitive url:/oneNet/NSADMIN), and then verify the information in the General and the "Authentication Domains" links is correct.

    The Authentication Domains should be the DNS name or IP address of an eDirectory server, usually one that holds a copy of the users partition.
    Also, verify the context information in here. This should reflect the highest context containing users that will use this middle tier - the LDAP contextless login search from the middle tier to the Backend will start at this container level and will only find objects that reside at this level or below.

    The General tab will indicate the
    (which is used for LDAP lookups of users' contexts). This should match the port listed in the LDAP Server Object for the authentication domain. This port will usually be 389 (it could be different if that port is already being used on the Backend server, e.g.: Active Directory).

    Note: Contextless Login will attempt to use clear-text LDAP access if the defined port is 289-489. If the defined port is outside of this range, Middle-Tier contextless login will attempt to communicate using secure LDAP.

    If you need to change any LDAP information on a NetWare server be sure to restart LDAP:
    unload NLDAP
    load NLDAP

  7. If your login fails to the /oneNet/NSADMIN url-
    See if you can authenticate to the oneNet/xtier-login url. If this login attempt works, but the NSADMIN one does not, then skip to step 9.
    If this login attempt fails just like the NSADMIN login attempt failed, first make sure your REALM is listed correctly (see
    TID 10091120).

    Next, try providing a DN for the username when prompted for credentials. So, for instance, after hitting /oneNet/xtier-login you are prompted with a login window, for the username use mike.provo.novell instead of just mike and this should tell you if you have an LDAP lookup issue.

    If logging in with the DN works, then the LDAP context lookup that is happening between the midtier and the Backend is not working.

  8. Check the LDAP Group Object -
    In the LDAP Group object for the Backend Server (EDirectory server that middle tier is pointing to)
    , verify that Allow Clear Text Passwords is checked (the ZENworks Middletier does not support LDAPS between the midtier and Backend... see
    TID 10082533).
    Note: If your eDirectory version is 8.7x or higher, this option is called Require TLS for Simple Bind with password and the option should be unchecked. If this is set correctly, then the LDAP lookup could be failing for another reason: the port (389) or authentication domain was misidentified during the installation.

    If you need to change any LDAP information on a NetWare server be sure to restart LDAP:
    unload NLDAP
    load NLDAP

    Since you cannot get to the oneNet/NSADMIN url to go change this, you can either re-install the middle tier or edit the registry keys that contain this value.

    Netware -
    If NetWare is your middle tier platform, use:8008 (the NetWare Remote Manager) and choose to modify the NetWare registry

    Windows- If Windows is your middle tier platform, then just substitute the myserver portion of the following regpath with HKLM). The registry path to get to the middle tier parameters is:

    myserver\software\novell\xtier\configuration\xsrvand\authentication domains.

    Also, ensure that the authentication domain contains a value that can be resolved from a ping attempt at the middle tier server, and also that key underneath the key contains a context that the users reside within.

  9. Ensure the proxy user is connecting to the authentication domain.
    You can tell if the proxy account is connecting to the authentication domain by looking for the proxy user's authenticated connection on the authentication domain server (if this isNetWare, use MONITOR; if this isWindows, use the Novell eDirectory Services control panel / Connections tab). These credentials are used to perform the LDAP lookup, and as such require enough rights and working credentials.
    Ensure that the proper rights are granted to this proxy user by reviewing
    TID 10082533.
    Also, ensure that the DN and password listed in the midtier's registry for the proxy user is correct. To do this, you can either reinstall the middletier and redefine the credentials, or go to the registry path for the middle tier parameters:


    In here you can change the proxy username and password that is specified. Just modify the key and erase the encrypted value, provide a clear text value (name has to be a DN, e.g.: admin.novell) and then the next time the middle tier modules restart, the values will be encrypted again IE:
    NetWare 6 -NVXADMDN and then NVXADMUP
    NetWare 6.5 -AP2WEBDN and then AP2WEBUP
    Windows- restart IIS Admin Service

  10. NW 6 middletier only-
    If you can authenticate through the /oneNet/xtier-login url, but not through the agent, it could be that the NetIdentity certificate being used during the agent authentication is corrupt.
    This has been seen to happen if the NetStorage option was chosen during the NW6 installation (ZENworks uses the same xtier architecture as NetStorage).

    To ascertain whether this is the problem, delete the NetIdentity certificate object from the Middle Tier's server container, go to the server console prompt and type INITCERT .
    This will recreate the certificate object. Now the middle tier needs to be restarted:
    (at the console prompt, NVXADMDN and then NVXADMUP).

  11. ZENWorks 6.5 NetWare-If you can authenticate through the /oneNet/xtier-login url, but not through the agent, it could be that the servers certificates are invalid. Run PKIDIAG on the server and validate the server certificates. You can verify which certificate is being used in NSADMIN on the General page.

  12. Windows middletieronly-
    Ensure that the credentials used as a Windows proxy account are administrator-level domain credentials.
    On the Windows Middletier, these are stored in:

    HKLM\Software\Novell\xtier\Configuration\LMAUTH\Proxy Username and Proxy Password.
    This account should be one that does not expire and is not required to change its password periodically.

  13. Windows Middle Tier only -
    Ensure that the oneNet extention is being handled by ISAPI - see TID 3732878"Error: "Page cannot be displayed" when accessing any Middle Tier URL"
  14. Windows Middle Tier only -
    netstat /a /n on a box in a failed state. This would tell us if we're running out of sockets. Do this also on the backend eDirectory server if it is windows platform.

    See KB 10090379 for tcp settings on Windows Please set MaxUserPort and TcpTimedWaitDelay

    Increase the threads for the IIS Web server.

    On the Windows server desktop, click Start > Administrative Tools > Internet Services Manager.
    In the Internet Information Services window, expand the Middle Tier Server icon > right-click the Default Web Site icon > click Properties.
    In the Properties dialog box, click Performance.
    In the Performance Tuning page > move the slider bar to increase the number of daily connections you anticipate for login through the ZfD Middle Tier / click Apply / OK.

    Additionally, set these Dword values for help Windows IIS for Windows 2000 servers only:


    Try disabling Hyperthreading on the Windows box.
  15. Agent Workstation-Make sure there is no firewall software on the workstation that is blocking the traffic to and from the middle tier server.

  16. eDir authentication works but AD Domain login fails. AD Domain policy was corrupt. Recreated it and authentication/login to both worked.

  17. Contextless Login fails for some accounts. Ensure that the CN is unique. If duplicate CNs exist, then the middle-tier server may use the wrong CN to attempt to authenticate.
  18. If LDAP is the problem, make sure the [Public] object has enough rights for anonymous binds:

Invoke ConsoleOne and select the tree you are interested in.

Right-click on the tree and select Properties. The "Properties of" window will appear.

Select Public from the list in the "Trustees of this Object" page under the "NDS Rights" tab.

Click the Assigned Rights button to bring up the "Rights Assigned to Public" window.

Click the Add Property button.

Select [All Attribute Rights] from the list.

Click OK to return to the "Rights Assigned To Public" window.

Select [All Attribute Rights]

Make sure"Compare” and "Read” and "Inheritable are checked

Click OK, OK
The following is a list of troubleshooting steps that should identify / resolve problems with the GINA when authenticating through the MiddleTier:
Below is a screenshot as an example of correct vs. incorrect login screens:
This screen is the Basic authentication dialog, instead of NetIdentity authentication dialog (note these are HTTP authentication dialogs, not GINA). Some reasons for this may be:

1. Validity of certificate being sent back from the middle-tier server. If navigation is not possible through the NW registry (either via NRM, or using the cdbe utility), confirm that the"Certificate Name" value under "My Server\Software\Novell\XTier\Configuration\XSrv" key is set either to "SSL CertificateDNS" or "SSL CertificateIP" (for a default install).

2. If the certificate name is set correctly, verify that the certificate and its key materials are valid. Use ConsoleOne to access this certificate on the middle-tier server and make sure that it passes validity and key material verification.
3. Check to see if "Strict Trust" value has been set to "1", or deleted on the workstation. This is present under the key"HKLM/software/novell/policies/client/netidentity". It should be set to 0, unless a real certificate (such as one signed by Verisign or another trusted CA has been installed and is being used instead of "SSL CertificateDNS").
4. Another cause of this problem has been the amount of free disk space available on the NW server running MiddleTier. Check to see that there is sufficient disk space available and restart the server (at least 1GB free)

Additional Information

Formerly known as TID# 10073537
Questions about Authentication processes and affect on object attributes (affecting Remote Management) in a ZW 7 Middle Tier environment.

Q. There is an attribute with the name zendmWSNetworkAddress on the user object. Which process is updating the attribute, and when? It is not updated immediately.

A. This attribute is updated by the Middle Tier server. It is updated typically every 29 minutes. Actually, its updated every time the Middle Tier server receives a request from a managed device.

Q. When the user logs in should it be updated directly?

A. The Remote management agent on the managed device without Novell client sends out a request to the server. This request is sent immediately when a new user logs in on that device. If the same user is present, the request is sent every 29 minutes. This is because the middle tier server maintains a timeout of 1 hour per session.

Q. The first thing seen when a user logs in is that the Middle Tier ipaddress is filled in. Is this proper?

A. If the middle tier server does not receive another request from a managed device, it deletes the attribute from that user's object. That is because this entry is fetched from the"Network address" attribute, which is populated automatically by eDir.

Q. Is it configurable?

A. Since the actual user logs into eDir from the Middle Tier, you can specify the IP addresses you want to filter out.

Q. To summarize:

--When a user logs in through MT, it will first use the network address and populate it to the attribute zemdmWSNetworkAdress.
--Then every 29 minutes the MT will update the attribute.

Is my understanding correct? Is there a way to change the interval that the MT will change the attriubte zemdmWSNetworkAdress

A. Yes, most of it. However, there is no way to change the interval, but you can disable it altogether.

Q. On the client side?

A. Yes

Q. What is the setting for it?

A. Actually, you can specify the time interval. The registry key is HKLM\Software\Novell\ZENworks\Remote Management\RMAgent, the value is: KeepAliveTime.
If this value is set to 0, it will not send the packets to the MiddleTier server. However, the timeout of 1 hour on the Middle Tier is not configurable. If the middle tier doesn't receive a request from a managed device within 1 hour, it will delete the attribute in the user object. So, actually for the IP address to appear seamlessly in the user object, the ping interval has to be less that 1 hour.

Q. One thing, in which case is the MT ipaddress populated in the attribute zemdmWSNetworkAdress?

A. When the Novell Client is not present on a managed device. When Novell Client is present on a Managed Device, the user logs in directly to eDir. There is no Middle Tier involved here. In such a case, the IP address is automatically populated by eDir in the "Network Address" attribute, and we needn't do anything extra in "zendmWSNetworkAddress" attribute.

Q. Sorry, when there is no Novell Client installed, only the ZFDagent, the MT will populate the MT address?

A. OK. When Novell Client is not installed on the Managed Device, two IP addresses will be populated in eDir, one is the address of the Middle Tier server in the "Network Address" attribute, and second the IP address of the Managed Device in the"zendmWSNetworkAddress" attribute. The first one (Network Address) happens automatically since the user actually logs in from the Middle Tier. The second one (zendmWSNetworkAddress) happens when the Agent sends the packet to the Middle Tier, and the Middle Tier populates it (ZENworks code) on behalf of the Agent in the user's object.