Use of "Already Verified" APPC Security from Invoking TPs

• SNA Server, versions 2.0, 2.1, 2.11, 2.11 Service Pack 1 (SP1), and 3.0

SYMPTOMS

Customers have often requested a capability for an invoking APPC transaction program (TP) to use security option "Already Verified", even in cases where the invoking TP was not invoked by some other APPC TP. This capability was always available in SNA Server, but somewhat inefficient in implementation. In SNA Server and other industry standard implementations of APPC, it is possible to implement a "pass through" TP, which could be invoked by the real invoking TP, and merely passes on the messages from the original invoking TP.

For a trusted APPC application, it is inefficient to issue originating (that is, invoking) APPC conversations on behalf of multiple users using APPC "Already Verified" security.

The direct approach would be to issue an [MC_]ALLOCATE APPC verb specifying both security=AP_SAME and an arbitrary username in the verb control block (VCB). The corresponding action in CPI-C would be to call cmscst(, CM_SECURITY_SAME,) and cmscsu( , <someUser> . . .), or provide this information in the symbolic destination definition. However, actually doing either of these results in an APPC conversation that ignores the value of the username parameter.

CAUSE

This limitation is behavior specified in version 1.2 of the WOSA WinAPPC and WinCPIC specifications. It has been implemented in other APPC libraries, such as Communications Manager 1.0.

RESOLUTION

The SNA Server WinAPPC and WinCPIC APIs will support an extension as follows:

• A TP was invoked by another TP, and now initiates a conversation specifying security type SAME:

  Any username that might be be specified in the VCB is ignored, and the system will provide the already verified username under which the TP was invoked, and set the "already verified" indicator in the outgoing conversation request. This behavior is unchanged.

• The TP was not invoked by another TP, issues a conversation startup request with security type SAME, and provides a user name: The system will copy the specified username into the outgoing conversation request and set the "already verified" indicator.
• The TP was not invoked by another TP, issues a conversation startup request with security type SAME, but does not provide a user name: The system will check for environment value: AP_SAMENOSUser. If this has a value starting with Y, the system will provide the current logged- on user name in the outgoing conversation request. If the environment value is not defined, or has some other value, the system will provide *no* username in the outgoing conversation request.

STATUS

Microsoft has confirmed this to be a problem in SNA Server versions 2.0, 2.10, 2.11 and 2.11 Service Pack 1 (SP1) 2.11. A supported fix is now available, but has not been fully regression-tested and should be applied only to systems experiencing this specific problem. Unless you are severely impacted by this specific problem, Microsoft recommends that you wait for the next Service Pack that contains this fix. Contact Microsoft Technical Support for more information.

REFERENCE

For more information on the UnverifiedAP_SAME registry entry (which has been replaced with the AP_SAMENOSUser registry entry in SNA Server version 3.0), please see the following article in the Microsoft Knowledge Base:

   Article-ID: Q135316
   Title     : Support for sending User ID on Attach when AP_SAME specified
               [sna]