User Aliasing is for sites running Prognosis Servers on multiple platforms (HPE NonStop, MS Windows, various UNIX versions) whereby the servers maintain separate user databases. This leads to a problem when the same user has different usernames on different hosts (as is almost certainly the case if the hosts are different platforms) and wants to execute a Command on a connected server other than the one that Windows Client is directly connected to. Normally, when a command is executed by a user from the Windows Client, the command runs as the username which that user logged on as. However, if the Command is to be executed on a remote server, that username might not even exist on the destination server, and the command execution will fail.
For example, the following diagram illustrates a situation where Peter is logged onto the Windows server NTSERVER17, which is connected to two other servers, the HPE NonStop server \NSK02 and the UNIX server SOLARIS03. His username on the Windows machines is syd\peter, but on the UNIX machine it is peter05 and on the HPE NonStop machine it is USER.PETER. He may even have visibility to other machines on which he does not even have a logon.
In either case, he will not be able to execute commands because the username he is logged on with to the Windows Client is not valid on the target machine.The diagram shows Peter logged on to \NTSERVER17 as syd\peter via the Windows Client. If he then tries to execute a command on the HPE NonStop server \NSK02 it will attempt to change user to \syd.peter, and will fail because that username is not valid on the HPE NonStop.
This situation can be resolved by using a SECURITY Configuration on each platform to map the usernames on the other platforms to the appropriate name on the target platform.
The following SECURITY Configurations would be used to resolve the issue of Peter running Commands on all the required servers.
Security configuration on \SOLARIS03
Security configuration on \NSK02
Command execution username mapping (Aliasing) only works on UNIX and HPE NonStop servers. On MS Windows servers, Commands are always executed as the user that started Prognosis.
Using the Alias parameter
The ALIAS parameter is used for Command 'Subsys' to specify the user to run as. If this extra parameter is present in the SECURITY Configuration of a server, it will allow the named <User> from any server to execute commands using the <Alias> on the \<Node>.
This entry implicitly grants the <User> on any server, access to shell commands on <Node>.
It is possible to be more specific or generic, for example:
This SECURITY Configuration grants:
Any commands from User_1 on \Node2 the User Id of Alias_1.
Any other User_1’s from other servers will run commands as Alias_2.
Any other users will run commands as Alias_3.
User Aliasing allows a list of alias mapping entries to be configured in the SECURITY Configuration. These are used to assign an Alias Id for user command requests coming from other servers.
As well as mapping individual usernames, wildcards can be used to map a whole set of usernames onto one particular username, as in the following example:
In addition, it should be noted that the command execution name mapping also acts on Commands run by the Automated Analyst. Normally, an analyst will execute Commands as the user who started the analyst, leading to exactly the same problem on systems with different user databases as with users directly executing commands. However, if a username mapping rule matches that user name, then the analyst will execute the command as the user name the rule maps it to. For example, in the above configuration, if an analyst is started on the HPE NonStop server with the configuration active by an HPE NonStop user in the IR domain, then the analyst will execute commands as IR.GUEST.
When a command request is received, it is matched against the Source User Id, Source Node and Command type specified in the SECURITY Configuration. However, a command request may match multiple entries in the destination SECURITY Configuration. Therefore, the purpose of 'Best Match' is to determine the most specific match of these criteria and then assign the applicable Alias Id.
Example Alias SECURITY Configuration on a Destination Node
Assuming that the following user requests satisfy the SUBSYSTEM, OBJECTTYPE, and FUNCTION requirements of SECURITY Configuration, the Alias Id is found by the best match as shown below:
Compare the Request attributes with the SECURITY Configuration and the 'Best match' is the entry that contains the most specific criteria.
Request 1 best matches Security syntax sample entry 3 as Source Node, Source User and Object Name are all specific matches, therefore Alias2 is assigned. Request 1 also matches all other syntax lines, but they do not have as many specific matches, the matches with a wildcard * are considered a lower priority match.
Request 2 best matches Security syntax sample entry 2 as Source User and Object Name are specific matches, therefore Alias1 is assigned
Request 3 best matches Security syntax sample entry 4 as only the Source User is a specific match, therefore Alias3 is assigned
Request 4 only matches Security syntax sample entry 1 where no Alias has been assigned. When the User Alias field in the entry is empty then the Source User name of the current request will be used.
When a SECURITY Configuration field contains a wildcard '*', it matches anything in the corresponding field of the user attribute. This match is called a 'weak' match. When a field is a specific value or string and the user’s corresponding field matches the field, this match is called a 'strong' match. When the checking takes place a 'strong' match will have a higher value than a 'weak' match and the first entry found with the highest value will be the 'Best Match'.
If the Alias field in an entry is empty, then the user name in the current request will be used.