When initially installed, default security uses the security configuration files with encrypted passwords based on the default secret phrase. The connection protocols are set to use Diffie Helman encryption and cleartext. With the default security, you need to change the passwords for the SDK usernames in the security configuration files. Default security prevents casual inspection, but does not pose much of a deterrence from more strenuous efforts.
It is essential that you change the default passwords for the usernames before using the system in a production environment.
While the default security provides basic authentication, it does not provide much manageability or security. The oper/oper credentials must be known to all console operators; the admin/changeme credentials must be known to all administrators. This makes it difficult to know who is actually connected to a server, based on their username. In addition, you cannot revoke the rights of one user without changing the SDK username and password for all users at the same access level.
The serverConnect.conf and clientConnect.conf files include authentication records that improves user administration. First, besides the oper/oper credentials, there are maint/maint credentials that also provide Monitor access. This illustrates how one might define shared usernames that are still differentiated on the basis of role. Second, serverConnect.conf contains the following line:
* : * : <SYS> : Monitor
Anyone who can provide a username and password that the operating system considers valid is also granted Monitor access. In this scenario, you can give every console operator an account on the host on which the server they access runs. These operators log in by using the username and password defined for that account. The account can be disabled to prevent actual interactive access to the system. In this way, each console operator gets a unique username and password. Accesses to the system can be traced to a particular user, and access can be individually revoked. Specifying <SYS> for the password avoids having to potentially create a number of records in serverConnect.conf.
This mechanism can readily be extended to provide similar controlled access for administrators. For example, you could add the following records to serverConnect.conf:
* : fred|george : <SYS> : All * : * : <SYS> : Monitor
This would give the users “fred” and “george”, if they provide the passwords for their accounts on the host, All access. You could even define a class of administrative users, for example, with usernames that start with ADM.
* : ADM* : <SYS> : All * : * : <SYS> : Monitor