Views:

The issue may occur because the policy host name is set to the fully qualified domain name (FQDN) even when only the domain name is required. To resolve this, change the policy name to domain name.

Another cause of this is when the PolicyServer is not properly resolving the domain host name to the domain controller. This behavior usually occurs within an organization with multiple or child domains. Add the following entry and enabled LMHosts to resolve this issue:

<X.X.X.X> DC <Name> #PRE #DOM:<NetBIOS name>

Where <X.X.X.X> is the IP address of the Domain Controller <Name> is the name of the Domain Controller (DC0001 for example) #PRE this preloads the entry on boot up <NetBIOS name> is equivalent to policy hostname (PLM for example)

This problem is caused by the CMOS battery in a machine to be dead or dying. The FDE refer to the BIOS date and time whenever a successful authentication takes place. Any changes on the BIOS clock can cause this 90-second window to be invalid and force re-authentication.

FDE has a security component built-in that requires re-authentication if it is not booted into Windows within 90 seconds.

To resolve this issue, change the following registry string from "1" to "0": HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon.

The Domain Authentication/Single Sign-On is not functioning properly and causes password synchronization problems.

The issue occurs due to the credentials being cached in the registry. The registry keys are located under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

To resolve the issue:

  1. Delete the following strings:
    • AltDefaultDomainName
    • AltDefaultUserName
    • AltDefaultPassword
    • DefaultDomainName
    • DefaultUserName
    • DefaultPassword
  2. Reboot your system.
  3. Authenticate to the pre-boot using your most recent password.

User A logs into the pre-boot and appears as User B in Windows. If you check the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, the Default UserName and DefaultPassword are populated with the User B's credentials.

To resolve the issue, do one of the following:

  • Browse to the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\\daWinLogon and create a string value called "OverWriteValue" and set the value "1".
  • Under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, delete the following string values:
    • AltDefaultDomainName
    • AltDefaultUserName
    • AltDefaultPassword
    • DefaultDomainName
    • DefaultUserName
    • DefaultPassword

    Method 2 is a reactive approach. Several issues could block FDE from deleting the Winlogon registry string values (i.e. DefaultPassword). The command that FDE uses to delete the Winlogon registry strings is RegDeleteValue. It is run as the System.

    If FDE is blocked from running the RegDeleteValue command, it could be caused by one of the following:

    • A setting within your group policy
    • Anti-spyware/Ad-Aware software blocking registry changes on the PC
    • Running the command RegDeleteValue as the System is being denied
    • Security Permission on the registry values

The Microsoft Windows NT specification for GINAs allows a concept known as "chaining" where one GINA.DLL can perform its role and then pass the authentication information to the next GINA.DLL. Due to the intensive integration with the OS, the Novell NWGINA.DLL cannot be chained to another GINA.DLL. Every third-party GINA can be different both in whether it allows chaining and how the implementation of this is accomplished.

The GINA that Windows initially loads is named in the following GinaDLL value in the registry. If the value is not present, Windows loads the MSGINA.DLL by default:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Unfortunately, Microsoft does not have a standard for where to store the name of the next GINA in the chain. Most third-party chaining GINAs store the next GINA to chain to in the registry. This means that if another third-party GINA is installed, they can potentially break the GINA chain.

Windows NT loads the GINA that is indicated by this Registry value:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL

If the value above is not present, Windows NT loads Microsoft's GINA, MSGINA.DLL.

For Single Sign-On, FDE passes two keys into the registry:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword

Then it changes the value: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Default\AutoAdminLogon from "0" to "1".

Once these are passed to the Windows GINA, the DefaultUsername and DefaultPassword are deleted. Those are all the same registry keys that would be changed for any program that wants to auto-login into Windows. Basically, we put the values in place and it is up to the next GINA in the chain to read them. Novell does not work well with other vendors in this area.

Boot time varies depending on the network connectivity.

As a workaround:

  1. Ensure that the LAN priority is higher than the wireless port, especially if LAN has DHCP enabled and WLAN does not.
  2. Disable WLAN until fully booted into Windows.
  3. If the disk is fully encrypted, disable the MABackfile service (MABFCSVC) in the Microsoft services console.

To resolve the issue:

  1. Confirm the last communication to PolicyServer by using either Cisco VPN Client (IPSec) or internal IP Address. If either of the above requirements is not met, the device may be locked due to failure to communicate with the PolicyServer within the set period of time.
  2. Check the password properties.
  3. Check the username on PolicyServer which is case-sensitive.
  4. Check the device group membership.
  5. Confirm Device ID and perform the Remote Help function.

To resolve the issue, wait for an amount of time as defined by policy in the PolicyServer. The device must be powered on and remain on during this time, and Standby Mode should not be activated.

To resolve the issue:

  1. Confirm the Device ID and perform the Remote Help function.
  2. Notify the user that if a reboot occurs, they must perform Remote Help.
  3. Advise the user to VPN prior to next reboot so communication can be established to the PolicyServer.

Do the following to fix the issue:

  1. Unplug the network cable.
  2. Log into FDE.
  3. Plug the cable back in once logged into Windows.

To resolve the issue, ensure that the User Name and Device ID are both in the same policy group.

You have a PC with an on-board video card, but you want to use an add-on card. When the card is added, the FDE pre-boot does not display.

If you want to add a second video card, the on-board video must be disabled. If you cannot disable the on-board card, then the new card will not work.

The PC boots to a blinking cursor during initial boot when a Maxtor One Touch USB hard disk drive is plugged into any PC and the USB is set higher in the boot priority than the internal hard disk drive.

As a workaround, lower the USB in the boot priority or unplug the drive.

Keywords: fix the authentication