Jump to content

PDRREF:Distributed Console Access Facility (DCAF) Architecture

From EDM2
Revision as of 04:25, 19 November 2019 by Martini (talk | contribs) (Created page with "{{PDRREF}} {{IBM-Reprint}} The IBM Distributed Console Access Facility (DCAF) product provides a remote console function that allows one programmable workstation, called a co...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Presentation Device Driver Reference for OS/2
  1. Introduction to OS/2 Presentation Drivers
  2. Design Considerations for All Drivers
  3. Graphics Engine/Presentation Driver Design Changes
  4. Design Considerations for Display Drivers
  5. Design Considerations for Hardcopy Drivers
  6. Display Drivers
  7. Distributed Console Access Facility (DCAF) Architecture
  8. Graphics Engine Hardcopy Drivers
  9. Queue Drivers
  10. Port Drivers
  11. Presentation Manager Function Categories
  12. Exported Driver Function Reference
  13. Mandatory and Simulated Graphics Engine Function Reference
  14. Device Support Function Reference
  15. DBIDI Command Structures and Command Flow

Appendixes

A - OS/2 Version Compatibility Considerations
B - Syntax Conventions
C - Format of the Journal File
D - Bit-Map Simulation for 16-Bit Hardcopy Drivers
E - Data Types
F - Notices

Miscellaneous

G - Glossary

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

The IBM Distributed Console Access Facility (DCAF) product provides a remote console function that allows one programmable workstation, called a controlling workstation, to control the keyboard and mouse input and monitor the display output of another programmable workstation, called a target workstation.

Operating States

The DCAF product has two main operating states: monitoring and active.

Monitoring State

When the DCAF session is in the monitoring state, the controlling-workstation user (hereafter referred to as the controller) sees a screen image of the target workstation's display. The target workstation user (hereafter referred to as the target user) has complete control of the target workstation operations.

Active State

When the DCAF session is in the active state, the controller operates and controls the target workstation. The keystrokes typed by the controller are relayed to the target workstation and acted upon as if they were typed by the target user. The keystroke input and the resulting screen image are seen on both the controlling and target workstations.

During the active state, keystroke input from the target workstation is not accepted. However, if the hot key combination is enabled for the target workstation, the target user can invoke this key combination to regain control of the target workstation. The target user also can choose to change the session state (for example, from active to monitoring).

The controller can establish concurrent sessions with multiple target workstations and can access each session by switching to a different window. Multiple controlling workstations can be defined within the network, however, only one of them at a time can establish a session with any single target workstation.

The controlling and target workstations are connected by a communication link.

The Sample DCAF Direct Connection figure above shows a direct connection between the controlling workstation and the OS/2 target workstation. Direct modem connections can be established between OS/2 workstations or between OS/2 controlling workstations and Windows Version 3.1 target workstations.

The Sample DCAF Connection figure above shows a connection via a DCAF gateway workstation that acts as an interface between the controlling workstation and the target workstations on a local area network (LAN). Connections through the DCAF gateway can be established from a DCAF controlling workstation to any kind of DCAF target (OS/2, DOS or Windows).

Benefits of using DCAF

Within a customer's network, DCAF's ability to monitor or control a remote workstation from a central site makes it a powerful tool for network management, network administration, network security, problem determination and diagnosis, and application assistance in the form of Help Desk functions.

This remote capability can save time and money, as well as increase the productivity of the administration and support personnel. Technical expertise can be centralized at the controlling site, reducing the need for highly skilled personnel at remote locations. Reduced operational requirements will decrease costs and allow for faster growth for distributed applications within the distributed intelligent workstation environment.

System management of a secure-session environment is streamlined and made easier with the location of the DCAF security administrator component at the controlling site. The DCAF secure-session security helps protect the customer's software assets because DCAF's logged connections create a security audit trail.

Typical Uses of DCAF

  • View and control another PC
  • Control unattended PCs remotely
  • Support customers and provide help remotely
  • Diagnose and solve problems on another PC by modem or over a LAN
  • Transfer text and data between PCs
  • Run DOS, Windows and OS/2 on an unattended PC by modem or over a LAN
  • Remote Help Desk assistance for applications, online education, and maintenance of application programs.
  • Remote problem determination for trace and dump analysis, including file transfer of data.
  • Remote control of unattended workstations (for example, LAN servers).
  • Remote management of Personal System/2 (PS/2) workstations and accessibility to data and programs stored on a PS/2 (for example, in the home or in the office) i.Remote access to system consoles when they are implemented on PS/2s.

Here is a typical scenario of the DCAF Help Desk function:

  • A target user is having difficulty understanding the company's new accounting program.
  • The target user contacts the Help Desk person who, in turn, opens a session with that particular target workstation.
  • With the target workstation accounting program on the screen, the controller (Help Desk person) switches to active state and types the correct keystrokes to run the accounting program.
  • The target user observes this process and learns how to use the new accounting program.
  • After demonstrating how to use the product, the controller switches to the monitoring state and returns control to the target user.

Understanding the DCAF Enviroment

DCAF offers two main levels of security, which limit users' ability to take over your target workstations. These levels, basic DCAF (or nonsecure) and secure DCAF, offer protection for your workstations to varying degrees. For typical nonsecure environments that deal with nonconfidential information, basic DCAF provides adequate protection. Secure DCAF is more complex and caters to environments, such as banks and insurance companies, that work with confidential material and require greater protection.

In order to be part of the DCAF environment, the workstations must have DCAF components installed.

The DCAF Components

Before you begin the installation, you should be familiar with the DCAF components. The role of each workstation in your network determines the component(s) you install on that workstation. All components, except targets, run on OS/2 workstations only.

You can install one or more components on the same workstation, but it is recommended that you install only the necessary components on each workstation. For example, on one workstation you might install a controller, on another, the gateway and LAN directory, and on a third, a target component.

=The Controller

The controller enables you to control the keyboard and mouse input and monitor the display output of a target workstation. It enables you to transfer files between the controller and target.

The Target

The target runs on three kinds of operating systems:

  • The OS/2 target enables an OS/2 workstation to be monitored and controlled by the controller.
  • The Windows target enables a Windows workstation to be monitored and controlled by the controller. The controller connects to the workstation whether it is operating in DOS full-screen mode or in a Windows graphic environment.
  • The DOS target enables a DOS workstation to be monitored and controlled by the controller. To install the DOS target, either create an installation package or use the CID method. Use the packager on an OS/2 workstation to create a DOS target installation package and then install the target on the DOS workstation.

In each case, the controller connects to the target directly if it is a basic DCAF target, or through a gateway if the workstation is secure.

The Gateway

The gateway links a controller with secure targets or with targets connected through an SNA backbone. The gateway always requires that you install a LAN directory on a workstation-any workstation-on the same LAN.

The gateway connects to all targets using the NetBIOS communication protocol. Therefore, install the gateway only in those parts of your network that use NetBIOS.

The gateway supports more than one session at a time so you probably need one gateway per logical LAN. To connect to secure targets, the gateway must be secure as well.

The LAN Directory

The LAN directory provides a list of the targets on a LAN that are available to the controller. When the controller connects directly with the targets via IPX/SPX, NetBIOS, or TCP/IP, the LAN directory is optional. When the controller connects with the targets through a gateway, the LAN directory is required.

Install one LAN directory per logical LAN. If you install more than one LAN directory on a logical LAN, give each a unique name.

The LAN directory also keeps a list that associates the workstation's physical address on the LAN with a nickname that makes the target name easy to remember. This list also enables the controller to find targets quickly. You can install the LAN directory on the target, gateway (if present), or on any workstation on the same LAN as the target.

The Security Administrator

The security administrator is necessary for secure DCAF only. It provides centralized maintenance of the databases for controllers, target access tables, secure target workstations, and security authenticators. Install one security administrator, typically on a controller, for your entire network if you are using secure DCAF. Safeguard this workstation from unauthorized access.

The security administrator keeps an encrypted database of authorized users, as well as an audit log file, EQNADMN.LOG. To be able to transfer security database files to the security authenticator, you must install either the security authenticator or a controller on the same workstation as the security administrator.

The Security Authenticator

The security authenticator is necessary for secure DCAF only. It authenticates sessions with secure targets. The security authenticator also gives access to secure targets based on security profiles for authorized controllers that it receives from the security administrator.

Install the security authenticator on an OS/2 target on the same LAN. Install it either on the security administrator workstation or on the secure OS/2 target workstation, so that it can receive security information from the security administrator.

If you install the security administrator on the LAN, you can install the security authenticator on the same workstation. Install at least one security authenticator for each logical LAN in your network.

The Packager

The packager is an installation aid only. It creates installation packages of DCAF components that you can install on other workstations. In addition, the packager enables you to prepare a component with the same personalization features to be installed in large numbers all over your network. Always install DOS targets using the packager.

The DCAF Network

The DCAF network includes the workstations that have DCAF installed and the communications that link them.

The Example of a Distributed Console Access Facility Environment figure, which follows, is one example of a basic DCAF environment.

The DCAF workstations communicate with the following communication protocols:

  • Advanced Peer-to-Peer Networking (APPN)
  • Advanced Program-to-Program Communication or APPC); more specifically, Logical Unit Type 6.2
  • Asynchronous (also called Asynchronous Communications Device Interface or ACDI)
  • IPX/SPX (except for DOS targets)
  • NetBIOS
  • TCP/IP (except for DOS targets)

Controller A communicates directly with target E and with gateway B using switched asynchronous communication.

Controller A also communicates, via LU 6.2 over a Systems Network Architecture (SNA) network or backbone, through gateway B to the targets on the LAN. The SNA backbone represents the part of the network that connects (via switched lines, leased lines, or satellite communications) host computers, communication controllers, and other computer hardware. Any connections over an SNA backbone must go through a gateway.

Controller A communicates directly with target F via LU 6.2. For LU 6.2 communications, the physical unit type for the controller, target workstation, and DCAF gateway workstation must be configured as a type 2.1 (PU2.1).

Controller A communicates via TCP/IP through a router with LAN directory I and with target H.

Controller A communicates via IPX/SPX through a router with LAN directory K and with target J.

Controller A communicates via NetBIOS directly with LAN directory M and with targets L, N, and O on the LAN.

OS/2 target workstations on the LAN require that OS/2 Communications Manager, LAN Adapter and Protocol Support (LAPS) from NTS/2, or the LAN Server 2.0 be installed to provide the NetBIOS device drivers. In order to run DCAF with other applications that require NetBIOS services, you may need to increase the NetBIOS resources via the OS/2 Communications Manager or LAN Services.

DOS target workstations on the LAN require that a LAN support program be installed, such as the IBM LAN Support product. DCAF supports DOS target workstations on the LAN only.

Levels of DCAF Security

DCAF provides the following levels of security:

  • Basic (Nonsecure)
    • No password
    • Password-only
  • Secure
    • Secure session

Basic (Nonsense) Level

A no password session exists between a controlling workstation and a gateway or target workstation for which a password is not defined and, therefore, is not necessary.

A password-only session exists between a controlling workstation and a gateway or target workstation for which a password is defined. The controller must type the password before the session can be established.

In both the no password and password-only cases, the target component was installed as basic, or nonsecure. Basic DCAF provides adequate protection for nonsecure environments that deal with nonconfidential information.

Secure Level

Secure DCAF offers a higher and more advanced level of security for environments such as banks and insurance companies that work with confidential material. You can make a target workstation almost impregnable to intruders by designating it as a secure target. The controller must access the secure target through a secure gateway.

A secure session exists between a controlling workstation and a gateway or target workstation that has been installed as a secure gateway or target. These secure workstations do not have passwords. Instead, the controller, authorized to access a secure gateway or target, has a personal pass phrase (a compound password) and an access-level profile for a specific secure workstation.

DCAF security works with the following communication connections only:

  • A controller can connect to a secure gateway via APPC/APPN or asynchronous.
  • The secure Gateway can connect to a secure target via NetBIOS only.

The Example of a DCAF Environment with Session Security figure shows some workstations in a secure DCAF environment. The gateway can use only NetBIOS to communicate with the secure targets. Secure targets must be on a LAN (see targets C and D in the following figure.)

Controller A communicates via secure gateway B with the secure targets on the LAN. When the controller wants to take over secure target C, security authenticator D verifies that the controller is authorized to access that workstation.

DOS or Windows target E on the LAN is not secure and does not require authentication. It has password-only security. Controller A can also establish a session with secure target workstation F. Typically, the secure DCAF gateway, LAN directory, and security authenticator reside on target workstation F. In this case, controller A connects to gateway F via APPC, and gateway F connects internally to target F via NetBIOS.

The security administrator is typically installed on a controller workstation. It provides security file maintenance, a message log file, and control access information used by the DCAF security authenticators, all in a central location. Security files are transferred from the security administrator via a secure session to all of the remote security authenticators. Security administrator workstation G transfers new or updated security files to security authenticators D and F.

When the controller wants to change a pass phrase, the security authenticator verifies the authorization before a session is allowed, and keeps a log file of the authentication activity. The verification compares the controller's input with the ciphered data stored on the security authenticator. The advantage of this mechanism is that there is no way to intercept or discover the pass phrase during transmission, because only the ciphered data is sent.

For auditing purposes, the gateway logs all session connections and the communication errors that it filters.

Code Modifications Required in Base Drivers

Seamless Windows Support