Host Authentication allows controlling whether D3 prompts for logon credentials or whether D3 uses the client's Operating System credentials for logging on. For regular telnet logons (that is, not nailed telnets), this policy is implemented using the Telnet Forced Host Authentication option which is set from the D3 Device Manager by selecting the Windows Security option from the Logon Security section in D3 Connect tab. All other logons (except RPC), automatically enable this policy. See D3 Settings for more information.
If enabled, clients attempting to log on to that machine will be prompted for their operating system user-id and password. These credentials are then passed down to the operating system for authentication. Note that 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 from DM, the Telnet Forced Host Authentication option must be enabled. Additionally, it must be enabled to use non-interactive processes that will be run on physical lines (such as phantoms and printers).
Anyone can logon as anyone by setting this configuration setting to prompt for credentials.
If disabled, clients attempting to log on to that machine 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 disabled, 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 this feature programmatically at runtime, see the U71 User Exit topic in the BASIC User Exits section of the D3 Reference Manual.
More Information
When logging on, the user enters their Windows user-ID and password. Authentication is controlled by the PDC of the Windows domain the service is logged onto.
RPC connections, such as those from the D3 File Manager or triggers, are not authenticated.
Clients will be logged into D3 using a user-id as described below:
Telnet clients connecting with HAForceCheck disabled will have the same user-id as the D3 process.
Telnet clients connecting with HAForceCheck enabled will be prompted for logon credentials and the provided user-id will be used.
RPC clients automatically connecting due to a trigger run from a telnet client will have the same user-id as the telnet client with $line$ appended.
RPC clients automatically connecting due to a trigger run from another RPC client (for example, the D3 File Manager) will have the same user-id as the D3 process with an "_" appended.
RPC clients logging into the VME (for example, the D3 File Manager in the Compile window) will have the user-id of RPC client process with an "_" appended.
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.
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. |
RPC connections from a D3TCL client to a D3 9.1 server are authenticated using the following rules.
If the DefaultD3TclHAForceCheck parameter is set to 1, the requirement to provide logon credentials is on and the system will behave as follows (Note that this is the recommended configuration because valid credentials are required).
For D3 9.1 Clients
If no credentials or invalid credentials are specified (for example, d3tcl or d3tcl -u nonexistentuser,badpassword), the logon will fail.
If valid credentials are specified (for example, d3tcl -u realuser,goodpassword), the client will be authenticated and logon as realuser.
If dm is specified (for example, d3tcl -u dm), the client will be authenticated and logon as dm.
For D3 9.1 Clients (Previous to 9.1)
If invalid credentials are specified (for example, d3tcl -u nonexistentuser,badpassword), the logon will fail.
If valid credentials are specified (for example, d3tcl -u realuser,goodpassword), the client will be authenticated and logon as realuser.
If dm is specified (for example, d3tcl -u dm), the client will be authenticated and logon as dm.
If DefaultD3TclHAForceCheck is set to 0, the requirement to provide logon credentials is off and the system will behave as follows.
WARNING |
It is not recommended to run in this configuration because pre-9.1 clients are not authenticated. |
For D3 9.1 Clients
If no credentials are specified (for example, d3tcl), the client will have the user-ID of the RPC client process with an underscore character (_) appended.
If invalid credentials are specified (for example, d3tcl -u nonexistentuser,badpassword), the logon will fail.
If valid credentials are specified (for example, d3tcl -u realuser,goodpassword), the client will be authenticated and logon as realuser.
If dm is specified (for example, d3tcl -u dm), the client will be authenticated and logon as dm.
For D3 9.1 Clients (Previous to 9.1)
Regardless of whether valid or invalid credentials are specified (for example, d3tcl -u nonexistentuser,badpassword), the client will not be authenticated but will logon as nonexistentuser.
If dm is specified (for example, d3tcl -u dm), the client will be authenticated and logon as dm.