User receives error when attempting to set their passphrase first time

  • 7940142
  • 19-Aug-2009
  • 07-Jan-2014

Environment

SecureLogin
SecureLogin SSO
All Versions
MS AD, LDAP, NT4, Citrix, Terminal Services, Novell Netware, eDirectory


Situation

Issue

Customer installed SecureLogin Single Sign-on on a user’s workstation. They then tried to start SecureLogin. They received errors when setting their passphrase and the SecureLogin client failed to load.

Resolution

Cause

If the passphrase system is enabled, the user’s passphrase is required to uniquely encrypt a user’s SSO data and protect their secrets. If a user starts SecureLogin and has never set a passphrase, they must set one before SecureLogin will load.

The most common reason a user is unable to save their passphrase is they don’t have the Directory rights to the Prot* attributes on their user object to do so.

ADS Solution

The error typically displays as -417 when the user attempts to set the passphrase.

Run ADSSchema.Exe to assign the rights and verify they have been done correctly. To assign rights, you will be prompted to define a context where you would like the user object rights to be updated from (e.g. OU=Users,OU=NewYork,DC=protocom,DC=com), allowing them access to their own SSO credentials. They will then be added automatically.

Required User object rights summary (users rights to their user object);

  • protocom-SSO-Auth-Data RW
  • protocom-SSO-Entries RW
  • protocom-SSO-Entries-Checksum RW
  • protocom-SSO-Profile R
  • protocom-SSO-Security-Prefs RW
  • protocom-SSO-Security-Prefs-Checksum RW

When ADSSchema.Exe is run, users are also automatically assigned the rights to read protocom-SSO-Entries, protocom-SSO-Profile and protocom-SSO-Security-Prefs at the OU level (so they can read published applications and settings for example).

LDAP Solution

When installing SecureLogin on an LDAP Directory other than ADS or NDS/eDirectory (e.g. Sun One), you may have to setup access control lists (i.e. make manual rights assignments) similar to those above so users can run SecureLogin.

Users also need the rights to read protocom-SSO-Entries, protocom-SSO-Profile and protocom-SSO-Security-Prefs at the OU level (so they can read published applications and settings for example).

NDS/eDirectory Solution

The error typically displays as -672 when the user attempts to set the passphrase.

Run NDSSchema.Exe to assign the rights and verify they have been done correctly. To assign rights, you will be prompted to define a context where you would like the user object rights to be updated from, allowing them access to their own SSO credentials. If you select (highly recommended) to set the rights from [root], the appropriate rights will be assigned to all users in the tree automatically.

Required User object rights summary (users rights to their user object);

  • Prot:SSO Auth - CRWA
  • Prot:SSO Entry - CRWA
  • Prot:SSO Entry Checksum - CRWA
  • Prot:SSO Profile – CR
  • Prot:SSO Security Prefs – CRWA
  • Prot:SSO Security Prefs Checksum- CRWA

Read and compare rights to the Prot:SSO Entry, Prot SSO Profile and Prot:SSO Security Prefs attributes are required on container objects (e.g. OU=Protocom) so users can read SSO enabled applications, settings, and predefined passphrase questions etc. These are also set when NDSSchema.Exe is run.

Note: In a Novell environment, some new users created using Netware Administrator have received error -672 and are unable to save their passphrase first time. Users who are created in ConsoleOne don’t receive this error because rights are automatically assigned. You may have to change the user template if you wish to use Netware Administrator.