Configuring the security file

In the security file you can specify which scheduling objects a user can manage and how. You define these settings by writing user definitions. A user definition is an association between a name and a set of users, the objects they can access, and the actions they can perform on the specified objects.

When defining user authorization consider that:
  • When commands are issued from the composer command line program, the user authorizations are checked in the security file of the master domain manager since the methods used to manage the entries in the database are invoked on the master domain manager. Therefore the user must be defined:
    • As system user on the system where the master domain manager is installed.
    • In the security file on the master domain manager with the authorizations needed to run the allowed commands on the specific objects.
  • When commands are issued from the conman command line program, the user must be authorized to run the specific commands in the security file both on the connecting workstation and on the master domain manager where the command actually runs.
The security file is parsed one line at a time, thus any given line in the security file has been assigned a maximum length of 32768 characters. Since during the encryption process (makesec), one extra character is added to any string value in order to store its length, the number of "visible" characters could actually be more or less than 32768. As an example, consider the following line: 
CPU=@+LOGON=test1, test2
The actual number of characters written into the encrypted Security file is determined according to this formula: 
 
"CPU=" : 2 chars (token) 
"@" : 2 chars (1 + 1 for the length) 
"LOGON=" : 2 chars (token) 
"test1," : 7 chars (6 + 1 for the length) (string) 
"test2" : 6 chars (5 + 1 for the length) (string) 
-------------------------------------------------- 
total : 19 chars
However, if counting the actual number of visible characters, there are 23 characters including the single space between test1 and test2 and the comma separating them.
Note: The "CPU" and "LOGON" each have a real length of two characters even though they actually have three and five characters respectively. This is because certain keywords are "tokenized." This can actually help reduce the apparent character count in this case.
The configuration of the security file is described in these sections: