This section provides information on the following:
When you install the Novell® SecretStore® service on the server, the installation program automatically does the following:
Creates an sssServerPolicy object.
Places this object in the Security container.
Assigns the name SecretStore to the object.
This object contains default settings for all users in the tree. You can customize security requirements for groups or users by creating sssServerPolicyOverride objects. The objects reside in the SecretStore (sssServerPolicy) container.
The SecretStore service first locates the sssServerPolicy object and then locates and uses an sssServerPolicyOverride object (if one exists). For more information on the sssServerPolicyOverride objects, see Section 1.2.2, sssServerPolicyOverride Object.
For information on how to create an sssServerPolicyOverride object, see Creating an Override Object.
Settings or policies determine SecretStore behavior in eDirectory™.
To view settings for SecretStore objects:
In iManager, in the view, click > .
Browse for and select the sssServerPolicy or an sssServerPolicyOverride object
Click .
Click the tab.
The SecretStore service caches some application-specific settings, such as those needed for NMAS™, to enforce Graded Authentication on ReadSecret operations. This cache helps the service respond to requests more quickly. The default is 30 minutes between refreshes of the server cache. The minimum is 30 minutes (1/2 hour). The maximum is 1,440 minutes (24 hours).
Consider increasing the time for the following situations:
You don’t make frequent changes to the policies that SecretStore uses.
Taking longer for SecretStore to enforce changes doesn’t matter.
You want to decrease the small overhead of refreshing data in the cache.
If you need to immediately update the cache, unload and reload the SecretStore service.
To have the SecretStore service record time stamp information on all ReadSecret operations, select .
By default, the SecretStore service doesn’t update the time stamp. If you want to update the time stamp when a secret is read, select the check box. Every read then becomes a write. Updating requires more time.
To disallow all Enhanced Protection Master Password options, select . When this option is selected, users can't set or use a master password to unlock SecretStore.
You can customize settings (for example, security requirements) for groups or users. You provide customized settings by creating and configuring an sssServerPolicyOverride object. When an override object exists, the SecretStore service first identifies settings in the sssServerPolicy object and then uses the customized settings in the sssServerPolicyOverride object.
You create sssServerPolicyOverride objects in the SecretStore (sssServerPolicies) container.
In iManager, in the view, click > .
In the field, specify a name for the new override policy.
In the field, specify or browse to and select the object where you want to create the override policy.
When you assign a policy to a User, the override settings take effect for that User only. When you assign a policy to a container, the override settings take effect for all objects in and below that container.
As a rule, set high-security policies (for example, biomentrics plus passwords) as defaults on the SecretStore object in the Security container. Set lower-priority policies on Policy Override objects.
Click .
After you verify that iManager created the override policy, click , or click to create a new override policy.
Each User or Container object can have an sssServerPolicyOverrideDn attribute that points to a particular sssServerPolicyOverride object. This attribute enables SecretStore to provide customized security for specific users located in various places in the eDirectory tree.
SssServerPolicyOverride objects override default settings found in the sssServerPolicies (SecretStore) object. These override objects can be children of sssServerPolicies, Organization, Organizational Unit, Country, Locality, or domain objects.
You should set the high-security policies (for example, biometrics plus passwords if NMAS is installed) as defaults on the SecretStore object in the Security container. Set lower-priority policies on sssServerPolicyOverride objects, found in the SecretStore container.
If the single sign-on client can’t find the SecretStore server that supports override objects, the client searches for any server that supports the default settings found in the SecretStore object.
To provide override policies:
Load sss.nlm with -o complete distinguished name of the override object.
For example, enter sss -o 2003specs.develop.digitalairlines.
A SecretStore server must support the override object. The -o 2003specs.develop.digitalairlines parameter specifies the distinguished name of the sssServerPolicyOverride object. You load this flag so that users have access to customized settings in the override object.
When users use an override object, all user workstation requests go to that server. This feature provides load balancing.
In iManager, in the view, click > .
Choose the User or Container object, then select .
If the override applies to all users in the container, select the Container object.
Browse to the desired sssServerPolicyOverride object, select the object, then click .
The sssServerPolicyOverride object is in the SecretStore (sssServerPolicy) container.
This step points the User (or containers) to the sssServerPolicyOverride object by setting the user’s (or container’s) sssServerPolicyOverrideDn attribute.
Scenario. Ming and Claire are in the RSDev.digitalairlines context. Markus and Rie are in the design.digitalairlines context. You want all four users to have security options provided in the sssServerPolicyOverride object named 2003SPECS.
You select Ming’s User object and then browse to and select 2003SSPECS. You repeat this process for Claire, Markus, and Rie. You load a server with the command line information so that these four users have access to the customized settings in 2003SPECS.