What does the NDSSchema.Exe tool do?
For SecureLogin to save user SSO data such as their usernames and passwords to applications, and to read SSO enabled applications and settings, the NDS/eDirectory schema must be extended and rights must be assigned.
NDSSchema.Exe must be run if you plan to use NDS/eDirectory as the SecureLogin data store, regardless of whether you wish to use the eDirectory or LDAP client. If you are using the LDAP client, you also need to run LDAPSchema.Exe to create LDAP group mappings.
It must also be run if you want to use SecretStore as the SSO data store. In SecretStore mode, the schema extensions are required as they are still used to store SSO encrypted data such as the user specific passphrase key, SSO enabled applications and SecureLogin settings, while actual logon credentials such as usernames and passwords are stored in SecretStore.
To extend the schema and assign the rights, first install the SecureLogin client on at least one workstation and run;
Tools\NDSSchema.Exe (located on the NSL CD).
Setup will first check to see whether the schema has been extended, before attempting to update it.
To extend the schema of a given tree, you must have sufficient rights over the [root] of the tree. The extension may take some time to filter throughout your network, depending on the size of your network and the speed of the links.
In Novell Directory environments the six new attributes are:
Prot: SSO Auth
Contains security data e.g. ""passphrase key""
Prot: SSO Entry
On both OU and User objects it contains data such as application scripts and settings, and against the user object only, it stores all the user IDs, passwords and other variables ($VariableName) for applications.
Prot: SSO Entry Checksum
Runs a check to ensure only âProt: SSO Entryâ data that has changed is synchronized between the Directory and the local cache.
Prot: SSO Profile
Redirects the object to read itâs SecureLogin configuration information from another container. Typically all applications and settings for a user are set in the Users parent container. User CN=MichaelC.OU=Users.OU=Utah.O=ACME would inherit applications and settings from OU=Users.OU=Utah.O=ACME. However, you could configure OU=Users.OU=Utah.O=ACME to read itâs SecureLogin configuration from another container such as OU=Users.OU=NewYork.O=ACME.
Prot: SSO Security Prefs
Contains passphrase configuration information such as predefined passphrase questions, passphrase policies, help text etc.
Prot: SSO Security Prefs Checksum
Runs a check to ensure only âProt: SSO Security Prefsâ data that has changed is synchronized between the Directory and the local cache.
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 (and save) their 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 set on container objects (e.g. OU=London) so users can read SSO enabled applications, settings, and predefined passphrase questions etc.
Note: If you install the client in NDS/eDirectory mode, you will not be able to start SecureLogin until you have extended the Directory schema and assigned user rights.