Environment
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.