Hi,

I have a doubt related to SLM Client, we have a BCLM Server or SLM Server running on Unix box (Server A ), and I did a client installation on another server ( Server B ), during installation of SLM client it broadcasted within network and found the available SLM server i.e. Server A, and I selected the same.

Now I can probably add new product , change activation key using SLM Client, so here goes my question ... don’t you guys think that here security is compromised , one can easily add SLM server available within network , and can perform changes and later on push the information back via SLM client to SLM Server ... so how is baan taking care of the security ... ??? :rolleyes:

Regards

Learner

I didn't test it but maybe could help if you protect file license.xml (and other xml files as well: servers.xml, product_number.xml, ...) - set permission for read only.

Yaah that could be a option, but its pretty strange as to how Baan probably overlooked it ..... ;)

Learner,

Refer to the documents -

Document code: U9200A US
Release: Infor Solution License Manager 7.0
Publication date: April 07
Infor_Solution_License_Manager_7_0_-_Administrator's_Guide.pdf

When to adjust SLM client configuration
If the SLM server is moved to another machine the SLM clients must be updated with the new machine name of the SLM server
(<SLMHOME>/etc/servers.xml). When there are multiple SLM Servers in an SLM Cluster the SLM Clients will automatically update the servers.xml as long as they can contact at least one of the SLM Servers in the cluster.

You have to be very careful handling the license file-

Document code: U9261A US
Release: Infor Solution License Manager 7.0
Publication date: April 07
Infor_Solution_License_Manager_7_0_Installation_and_Configuration_Guide.pdf

Single point of maintenance
Don’t adjust the license configuration of an SLM Cluster from two places at one time. SLM configuration is not equipped for parallel configuration management. It will detect it when parallel updates are taking place and give warnings on that, but you need to resolve the problems yourself in that case. To prevent data inconsistency, SLM uses license version numbers as an implicit locking mechanism. Initially, the version number of the license file can be any number.
Each time you activate or modify and save a data file to the server, the version number increments by one. The server will be locked for all files with a version number that differs from the new version number. As a result, if more than one person modifies the license data from several points, and one submits changes to the server, the server is locked to all persons except the one who made the modification.

This version number is used to keep track of all the changes on the license file, and is additionally used as an implicit locking mechanism. Each time a data file is saved to the server, the version number is incremented. The server will be locked for all files with a version number that differs from the current version number plus one.
Note: Because of this locking mechanism, there must be one single point of
maintenance. If more than one person modifies the license data from various points, and if one person submits changes to the server, the server is locked everyone except the person who made the modification.

Note 1: If you change in the XML files on the server the values of the active fields by hand, the activation key is no longer valid and the SLM engine becomes unavailable. If you adjust the files with the SLM Management UI, however, you can reach the active fields and the properties you modify get the Change, Add, or Delete status. These changes do not become active until a new activation key is submitted.

To submit a new file
The following table describes the syntax of the commands to save new data files to the license server. Only a master license server can handle modification of the license data.

There is a parameter in the SLM license.xml:
clientUpdate=”Yes” #clients automatically sync’d
If that is set to Yes the SLM Server will automatically sync and overwrite the license file on the client server.

It is up to you to figure out if it worth tweaking the license files and putting the corporate ERP system at risk and unusable. You might end up writing a Root Cause Document or in some extreme situation. If you find a bug then log a case with Baan support and they would fix it, that's more positive approach.