Extending Schema for NSL on LDAP v3 compliant Directory

Directory Server schema extended using an LDIF file.

3rd party LDAP

Non eDirectory or Active Directory installs

When installing SecureLogin on an LDAP Directory other than ADS or NDS/eDirectory (e.g. Sun One, Critical Path), you must setup access control lists (i.e. make rights assignments) so users can run SecureLogin.

For example, users need read and write rights to store their passphrase security key and also write rights to encrypt and save application logon credentials against their user object in the Directory.

The required rights users must have to their user object are as follows:

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

For centralized administration and management of the product, users must be able to read (but not write) SSO data, such as SSO enabled applications, corporate password policies and corporate preferences, defined at the corporate level (e.g. against Organization and Organizational Unit objects such as OU=Users,DC=New York,DC=ACME,DC=COM).

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. CN=Users,DC=testdc,DC=com), allowing them access to their own SSO credentials. They will then be added automatically.

The required rights users must have to O and OUs are as follows:

• protocom-SSO-Entries R
• protocom-SSO-Entries-Checksum R
• protocom-SSO-Profile R
• protocom-SSO-Security-Prefs R
• protocom-SSO-Security-Prefs-Checksum R

Note: protocom-SSO-Auth-Data only applies to user objects as it stores user specific data such as the passphrase.

All SecureLogin data is protected from unauthorized access in a number of ways to maximize the security of the product. At the raw database level data is protected by Access Control Lists (ACLs)/Directory rights assignments. When SecureLogin is installed, in LDAP Directories such as Critical Path and SunOne, ACL’s must be configured.

The ACL’s/rights enable users to read and write SSO data stored against their user object (but not others). For example, users require the ability to read and write their passphrase, application usernames and passwords etc.