Host Authentication

Host Authentication is a D3 feature that allows use of the operating system to provide authentication of logon credentials when logging into D3. By default, the client is automatically logged into D3 using their operating system logon credentials rather than being prompted for their traditional D3 user and password. To enable this option, the hostauthentication on entry must exist in the pick0 configuration file at the time D3 is booted (see the pick0 File topic in the D3 Reference Manual for more information). Also, the OpenSSL package needs to have been installed onn AIX prior to the linking of the D3 monitor during the install of D3 (that is, prior to running D3_setup).

Host Authentication with the haforcecheck option

By using the haforcecheck option, the user can still be challenged for a user and password upon logon to D3, but the user and password are authenticated against the operating system, not the traditional D3 users file (see the d3 Command topic in the D3 Reference Manual for more information). If this option is used during virtual machine startup, clients attempting to log on to that machine will be prompted for their operating system user and password. These credentials are then passed down to the operating system for authentication. Note that UNIX user-ids are case-sensitive.

This option ignores any passwords set up in the users item (if the users item exists). If the users item does not exist, users will have SYS2 privileges but no Virtual Debugger access. To specify different privileges, you can create a custom users item. In order to logon as DM, this option must be used. Additionally, non-interactive processes that will be run on physical lines (such as phantoms and printers) also require this option. Anyone can logon as anyone by using this option to prompt for credentials.

If this option is not used, clients will not be prompted for such credentials and will be taken directly to the md prompt. Note that doing an off behaves the same as an exit since the logon prompt was bypassed during the initial log on.

WARNING

If this option is not used, anyone with access to your network that can connect to a D3 port (for example, telnet or nailed) will have access as whatever user D3 is running as. This includes the ability to shell out and run OS commands.

To employ the haforcecheck option programmatically at runtime, see the U71 User Exit topic in the BASIC User Exits section of the D3 Reference Manual.

More Information

Nailed telnets automatically use the haforcecheck option. Otherwise, anyone that has access to connect to the nailed port will automatically logon as the user that started the D3 process (which may be root!).

When configuring lines that will be logged onto existing processes (those started by root), it is recommended you use the haforcecheck option to challenge clients for logon credentials.

For Phantoms:

Passwords are encrypted because they must be temporarily stored in the jobs file.
Queued phantoms will fail to run (fail to logon) if the authentication mode is changed (and D3 is rebooted) because the logon credentials specified when the job was queued no longer apply to the authentication mode in use.
Users that have access to change and compile BASIC code that collects passwords, such as dm,bp, z, can modify such a program to obtain passwords in plain text. If this is a concern, it is important to take appropriate measures, such as deleting the source code to dm,bp, z so that it cannot be changed easily to do this.
D3 uses the PAM d3 service configuration. This is where a system administrator can make changes that effect D3. It is based on the login service, but does not use securetty. Enabling securetty will create the same restrictions as logging into the OS shell (in other words, the securetty file must have the tty of the client listed if they are going to login as root). Furthermore, a phantom does not have a tty. Therefore, if securetty is enabled then non-root users will not be able to run phantoms as root.

WARNING

When a phantom is scheduled to run as a user other than the one starting the job, they will be challenged for a user-id and password (as usual). If strong encryption (for example, AES) is not available to D3, the password will be encrypted using a very insecure 1-bit shift algorithm.