Cannot unlock Windows 7/Vista/2008 with eDirectory Credentials

  • 7005917
  • 06-May-2010
  • 18-Nov-2013


Novell Client for Windows Vista
Novell Client 2 for Windows Vista/2008
Novell Client 2 SP1 for Windows Vista
Novell Client 2 SP1 for Windows Server 2008
Novell Client 2 SP1 for Windows 7
Novell Client 2 SP1 for Windows Server 2008 R2
Microsoft Windows 2008
Microsoft Windows 7
Microsoft Windows Vista


After customizing an install with NCIMAN, Novell Client 2 SP1 is installed on Windows 7/2008/Vista.  The Client installs without error and the workstation is rebooted.  After login, the workstation is locked.  Upon unlock, the user receives the following error message:

The network password cannot be validated at this time because the connection to the Novell network was lost. Please enter the password for the Windows account to unlock the computer now, or wait and try the network password again later.

The windows credentials will work to unlock the workstation, but this is a major annoyance.

Conversely, if the customized installation is removed and the Novell Client 2 is installed unmodified, all works as expected with regards to the lock/unlock.


The above message is a valid error message and can be returned properly for a number of reasons including networking issues (infrastructure), workstation/end device configuration (i.e. hibernation/power saving on the network interface), etc.  Having said this, there are also a couple of instances where this error message is being returned incorrectly.  They include:

  1. There is not a sequence available on the NMAS tab. 
    A fix has been made in "Novell Client 2 SP1 for Windows (IR3)" (or later) that is meant to address this message being returned incorrectly.

    Therefore, if you are running earlier code, please update to"Novell Client 2 SP1 for Windows IR3.exe" or later.  If you still get this error message and you have:

    - disabled power saving features on your network interfaces
    - disabled hibernation on your system

  2. NMAS is configured but SIDs are changing due to users being created and removed dynamically.
    NMAS will use user SID # security on NMAS data stored locally (see Internal Error 0xFFFFFA27 for more details).  In this case, changing the NICI data to be stored in the user's home directory, vs. a location under the NICI directory, resolved the issue.  To do this, the following registry entry is required:

    Windows Registry Editor Version 5.00


If neither of the above resolve your issue, then please contact Novell Technical Services for further assistance.

Additional Information

Before the code fix in IR3, you could easily verify this to be your issue by:

1) Disable NMAS on the computer in question
2) restart the OS
3) login & try to lock & unlock the workstation.

if you are now successful, you are experiencing this issue.

The best solution is to update the client to the latest code.  If you cannot quickly/expediently do so, you can do one of the following:

A) Add the following registry entries & restart the system:


(see NOTE: below)

B) Update the Unattend.txt (generated by NCIMAN) to include the following:

    !LoginProfilesDWOn5="Default\Tab4","Display Clearance"

and reinstall the client.   
(see NOTE: below)

C) Launch NCIMAN.EXE and follow these steps:
     a)  file-open-<yourSettingsFile>
     b) Settings
     c) click Default & Properties
     d) nmas tab
     e) uncheck "enable tab"& recheck "enable tab"
     f)  click OK
     g) click SAVE
and re-install / install the client.

(NOTE: in the above examples, Tab4 was the actual value used to trouble shoot in a lab environment.  "Tab4" should actually be the next, unused "Tab" value in the registry.  For example, if your registry already contained:


then "Tab6" would be appropriate to use).

Change Log

17 Aug 10 mgould - Moved workaround to Additional Info and added fix to Resolution.
08 Sep 10 kklemm - Received a couple of feedback indicating that the feedback provider still sees this message after applying IR3. 
     - Updated the resolution section to reflect that IR3 only resolves one given cause of the error being returned & updated to file name vs. title as file name is Windows version agnostic
     - Left the workaround / additional information public in case customers can't quickly upgrade to IR3; they can use the previous workarounds to address this in pre-IR3
29 Jul 13 kklemm - Added feedback from customer as resolution #2