How to configure Novell SecretStore Services to stop tree walking.
(Last modified: 04Dec2005)
This document (10091039) is provided subject to the disclaimer at the end of this document.
Novell SecretStore Services
How to configure Novell SecretStore Services to stop tree walking.
How to configure the SecretStore client to connect to specific server(s)
The SecretStore client keeps walking to the root of the tree.
SecretStore client connects to undesired servers
SecretStore is causing high utilization on my server.
What is the sssServerPolicyOverride object?
What is the Policy Override Object?
Should the sssServerPolicyOverrideDN object be the full name and context?
What is the sssActiveServerList?
What servers are reported as the sssActiveServerList?
Novell SecureLogin intermittently reports LoadSSOData errors when installed with SecretStore Services.
Novell SecureLogin will intermittently hang or slows down when trying to access SecretStore data.
Novell SecureLogin modules slbroker or combroker intermittently appear to go to not responding or using all of the workstation resources
The answers to the above questions are answered in a brief discussion of how the SecretStore Services client actually locates data within the tree. Proper configuration of SecretStore within the tree will effect how the SecretStore Services client will behave.
This discussion will include screenshots of actual packet traces showing how SecretStore Services works within eDirectory. We will also discuss proper configuration techniques to make this operation more efficient.
To understand how SecretStore stores data within eDirectory you should refer to the Novell documentation on SecretStore Services.
SecretStore data is held within attributes of each user object that is utilizing SecretStore Services. The contents of the attributes are in encrypted form and can only be decrypted by the SecretStore Services module running on a eDirectory server. Since the data is stored on each user object, it is important to have at least one server for each user partition running SecretStore Services. In many cases you may want at least 2 servers for each user partition running SecretStore Services for fault tolerance.
When the SecretStore Services module loads on an eDirectory server it registers itself as an sssActiveServerList object. This is an attribute in eDirectory that contains the listing of all active SecretStore Services servers in the tree.
When the SecretStore Services client initializes on the workstation it must locate a SecretStore Services server. It does this by querying eDirectory for the sssActiveServerList.
eDirectory then returns a listing of all servers that have registered as an active server. The client will then ping each server in the list to determine which servers can service our requests for SecretStore data. If the connection server (the server the currently connected to) can handle SecretStore requests for the client, the client will initiate a SecretStore conversation with the connection server, and will go no further. Otherwise, the SecretStore client will establish a connection with the first server to respond to its ping.
But what happens if I have hundreds of servers? I don't want the SecretStore client to have to ping each one. I also don't want the SecretStore Services client reading the secrets from a server across the WAN link.
We should properly configure SecretStore Services in the eDirectory tree so that we eliminate tree walking and improve the efficiency in finding the local server. We do this by defining a sssServerPolicyOverride object in the tree. First of all, lets look at a sample tree design.
In our example the main servers HSSJDS01 and SCRSDS02 house a copy of every other replica in the tree. One quick thought would be to just place SecretStore Services on these servers. But if we do this then every user will be forced to talk to one of these servers for their SecretStore information. Thus, users would be walking over WAN links to get SecretStore data. This doesn't mean that we cannot load SecretStore Services on these servers but we must ensure that we properly configure SecretStore so that the local servers will be preferred over the main root servers.
Our user will exist in the context NSLTEST.AATEST.CSB.SC.STJOHN. Notice that we have a partition at the CSB container. The most logical place for our users in this container to access their SecretStore data would be from a server from within this container. This would be the servers SCCBFS02, SCCBFS03, and SCCBFS04. We could load SecretStore Services on these servers only but we have users in other containers throughout the tree. We must load SecretStore on many servers and they all should be able to service requests for their respective users.
So when the SecretStore client initializes for our user in the NSLTEST container, the first thing the client does is it looks for an attribute in eDirectory to determine how it should function. The attribute it looks for is the sssServerPolicyOverrideDN. The client starts at the user object and then walks down the tree until it reaches [Root] to find any SecretStore policies.
Notice that in the packet trace we Resolve the name of the object we are looking for, and then we request to read the attribute and it's value for sssServerPolicyOverrideDN. We continue to walk the tree until we either find an override policy or we reach the root of the tree.
The sssServerPolicyOverrideDN provides serveral different functions. First of all it is the mechanism that allows you to configure specific administrators who can manage SecretStorer services, You can also set synchronization times and configure the master password operations. But a secondary function of the sssServerPolicyOverrideDN is to stop tree walking (i.e. stop looking for SecretStore servers). If the name of the policy matches the partition name then the SecretStore client will consider that server to be the root of the tree. For instance when we resolve the container and then read the attribute value and they match, we no longer do anymore walking and we use that server and all servers listed in the active server list for that partition for our SecretStore information. Our first step is to create the sssServerPolicyOverride object in the Security container with ConsoleOne.
Our user is going to be logging in from the CSB container so we want to create a policy with the same name.
Now we browse the tree to the CSB container and go to the properties of the container object.
From the SecretStore tab we will now select the correct policy.
Now that we have configured SecretStore Services in eDirectory we will need to load the SecretStore Services module on the server with the override object. It is important to note that SecretStore can be loaded on all platforms supported by eDirectory but for this example we will only see the Novell server console.
SecretStore Services might already be loaded on your server. In the following we will discuss options if you need to unload SecretStore Services. But for our example:
We need to load the sss.nlm with the /o switch. This is the alpha character o not the number zero. Then the equals sign and the full distinguished name of the policy object. In our case this is csb.SecretStore.Security.
We should also see on the logger screen that the DN was assigned and it is the name of the object that we defined in ConsoleOne.
Manually loading SecretStore Services is not necessarily an easy task. The reason for this is because it is autoloaded by NLDAP when it loads. For this reason you have two options.
1. Edit the Autoexec.ncf to manually load SecretStore Services prior to NLDAP. You will probably want to make this change anyway. And then restart the server.
2. If you cannot restart the server you can manually unload and reload SSS but you will need to unload and reload the modules that are in use.
Congratulations: Now SecretStore Services is configured for the container and we should not see any excessive tree walking by the SecretStore client.
We now see that when we resolve the CSB container, we then read the sssServerPolicyOverrideDN attribute for that container.
We see in the decode window of our analyzer that the server response returns the name of our Policy Override object.
The SecretStore client now needs to see if the name of the Policy Override object matches the partition root information. So the client performs a Get Replica Root ID and determines the object ID for the partition root. It then reads the Entry Information on that ID and finds that it is the CSB container.
Now the client knows that this is the location where it needs to get it's information from. The next step is to locate the SecretStore servers that can supply SecretStore information.
The sssActiveServerList is a listing of all servers that contain a replica of this partition and are running SecretStore Services.
The server returns the list of active servers. Unfortunately the list is stored in NDS as a Binary String. So, how do we know what servers are in the list.
When you highlight the actual string in the decode pane the actual data is highlighted as well in the data pane. As you can see the Binary String that is highlighted is for the server SCCBFS03.CSB.SC.STJOHN. Also note that the Override object is also part of the Binary String. In this example it is csb.secretstore.security. Hey this matches what we read from the override policy attribute.
The client now starts resolving the names from the active server list and gathering addresses. The client needs this information to connect to SecretStore.
The SecretStore client will now begin pinging each of the SecretStore servers from the list to ensure that it can communicate with each one. You should see a ping go out for each of the server in the active server list that matches the override object. If the override object does not match any of the servers in the list then SecretStore will continue to walk the tree.
Finally, the SecretStore Services client will make a connection to one of the servers that responded to it's SecretStore ping and will start doing it's work.
It is important to note that SecretStore Services will always fall back to walking the tree if for some reason none of the servers in the active server list cannot respond. This is working as designed so that environments can design for fault tolerant conditions. In our example two fo the servers that were listed in our active server list were the root servers. But the override policy object for those servers does not match our currently defined override object. We will not communicate or even try to ping those servers unless we fail on all of the other servers that do match our policy override object.
In cases where there might only be one replica at the offsite location and then one or more servers across the WAN link from the user. Create a unique override policy object for the 1 replica server. Under normal conditions when that server is available then it will service all of the users requests for SecretStore data. But if for some reason that server is down, the SecretStore client will walk up the tree to one of the remote servers to acquire SecretStore data.
NOTE: The packet traces above were decoded by Ethereal. You can download Ethereal from http://www.ethereal.com.
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.
- Document ID:
- Solution ID: NOVL95491
- Creation Date: 06Feb2004
- Modified Date: 04Dec2005
Did this document solve your problem? Provide Feedback