Managing SecretStore Objects

This section provides information on the following:


SecretStore Objects

When you install the Novell® SecretStore® service on the server, the installation program automatically does the following:

The following figure illustrates this object:


The SecretStore 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 following figure illustrates an override object:


sssServerPolicy Override Objects

The SecretStore service first locates the sssServerPolicy object and then locates and uses an sssServerPolicyOverride object (if one exists).


Viewing and Changing Settings on Objects

Settings or policies determine SecretStore behavior in eDirectoryTM.

To view settings for SecretStore objects:

  1. In ConsoleOne®, select the sssServerPolicy or an sssServerPolicyOverride object.

  2. Right-click, then click Properties > Novell SecretStore.

  3. Select an option (for example, General).


Setting Minutes between Cache Refresh

The SecretStore service caches some application-specific settings, such as those needed for NMASTM, 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:

If an immediate update of the cache is needed, unload and reload the SecretStore service.


Updating the Time Stamp

To have the SecretStore service record time stamp information on all ReadSecret operations, check the check box for this setting.

By default, the SecretStore service doesn't update the time stamp. If you want to update the time stamp when a secret is read, check the check box. Every read then becomes a write. Updating requires more time.


Disabling Master Password Operations

To disallow all Enhanced Protection Master Password options, check the check box for this setting. When it is checked, users can't set or use their master password to unlock SecretStore.


Customizing Settings for Groups or Users

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 sss.nlm program (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.


Creating an Override Object

  1. Right-click the SecretStore (sssServerPolicy) object, then click New.

  2. Select sssServerPolicyOverride, then click OK.

  3. In the Name field, specify the name of the group or user that the customized settings will apply to.

    Use the complete context (for example, design.mresearch.vmp). If the name is incomplete or incorrect, the SecretStore service is unable to match the sssServerPolicyOverride object with the group or user.

  4. Set server settings.

    Select the Define Additional Settings check box and customize the settings (for example, Disable Master Password Operations). The help system provides information about each setting.

    You can also select the Novell SecretStore > Administrator option to specify SecretStore administrators for this object.


Customizing Security throughout the Tree

Each User or Container object has an sssServerPolicyOverrideDn attribute that can point 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.

As a rule, 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:

  1. 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 flag 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.

  2. Right-click the User or Container object, then select Properties.

    If the override applies to all users in the container, select the Container object.

  3. Click the Novell SecretStore tab, then click Policy.


    Setting an sssServerPolicyOverrideDn Attribute

  4. Browse to the desired sssServerPolicyOverride object, select the object, then click OK.

    The sss/ServerPolicyOverride 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.