"SecureLogin encountered an error while trying to authenticate"

Error returned when NSL launches:  "SecureLogin encountered an error while trying to authenticate"
Problem occurs when passphrases are disabled, a user is renamed or moved, AND an administrator resets the user's directory  password.

Workaround:  Login at least once between the move / rename and the change password operations.

Unfortunately, this is working as designed, and is one of the problems with disabling (hiding) passphrases.

When SecureLogin is launched it authenticates to the directory and opens the user's NSL data, authenticating with the user's eDirectory password. If, however, this password has been changed by an administrator, this authentication fails. At this point the user would normally be prompted for his or her passphrase to verify his or her identity. But when passhrase security has been disabled (hidden) the user's GUID (based on the fully distinguished username, including the context) is used instead of a passphrase to authenticate to eDirectory. If this GUID has been changed by moving or renaming the user it also becomes invalid for authentication.

With hidden passphrase there is no problem renaming or moving users until the administrator resets the user's eDirectory password. When that password changes the existing primary authentication key (password) becomes invalid. NSL then rolls over to the secondary authentication key (passphrase or GUID) - which in this case would also no longer be valid, because the GUID has also been changed.

In general, Novell does not recommend hiding passphrases, but recommends that passphrase security be left intact. However, in an environment where passphrases have been hidden, if users are to be renamed or moved Novell recommends the following approach:

1.  user A (uid= userA) has NSL running perfectly, primary encryption key is based on the user's login password and secondary key is hidden pass phrase.
2.  administrator changes the pass phrase mode to on. Administrator can pre populate the passphrase questions, so that user inherits them.
3.  at next SSO startup, userA is prompted to select a passphrase from the prepopulated list and to answer this passphrase question
4.  by doing so, SecureLogin updates the secondary key and computes it based on the passphrase answer that has been provided
5.  administrator changes the username from userA to user AA and resets the userA's password
6. user A logs in again using new uid userAA and new password
7. SecureLogin starts and is unable to decrypt the data as password has changed. As a consequence, it rolls over the secondary key mechanism and prompts for the user's passphrase answer.
8. userAA provides the correct passphrase answer; SecureLogin starts and updates the primary key with the new password.
9.  administrator can now reset the passphrase mode to hidden for userAA
10. at next NSL startup, user gets a message saying that the passphrase mode has changed to hidden. User accepts the message
11. by doing so, SecureLogin updates the secondary key and computes it based on the new user GUID

Novell also recommends this procedure to customers with hidden passphrases who are  migrating from one domain to another.

Steps to duplicate:

1.Create new user.
2.In iManager, SecureLogin, Manage SSO, Advanced, set the datastore to 6.0
3.In iManager, SecureLogin, Manage SSO, Preferences,  set “enable passphrase
security system” to hidden
4.Login as  the new user, make sure SecureLogin launches successfully
5.In iManager, Users, rename or move the user.
6.Login as the newly moved or renamed user and launch SecureLogin.
Repeat several times, even rebooting between iterations. Each time SecureLogin will launch without error.
6.In iManager, Users, Modify user, Restrictions, change the password
7.Login as the user on a workstation running NSL6.0.x or NSL6.1.x.  Error will be
returned: "SecureLogin encountered an error while trying to authenticate"