Persistent Verification Support for APPC Sessions

 Last reviewed: February 11, 1998
Article ID: Q180866
The information in this article applies to:
  • Microsoft SNA Server, versions 3.0, 3.0 SP1, 3.0 SP2

SYMPTOMS

SNA Server 3.0 does not include support for Persistent Verification (PV), a method for managing conversation level security on an APPC session. Without PV support, a sending LU cannot send a password on the first ATTACH and set the PV bit. The PV bit signals the receiving TP to check the security credentials by verifying the password.

CAUSE

Persistent Verification support was not implemented in SNA Server 3.0.

STATUS

Microsoft has confirmed this to be a problem in SNA Server versions 3.0, 3.0SP1, and 3.0SP2. 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 Product Support Services for more information.

MORE INFORMATION

PV changes were implemented in SNA Server 4.0 but were not fully retrofitted to the SNA Server 3.0 product. In addition, modifications to the APPC interface (Wappc32.dll) were needed to provide correct interaction between PV and Already Verified (AV) support, which is a second method for managing APPC conversation level security. With the hotfix applied, if the host will accept AV and PV, and the APPC application specifies "security = AP_SAME", SNA Server does the following:

  1. If it does not detect that the user is signed on to the host, it sends an ATTACH with the AV bit set and the PV bits set to "sign-on requested". A password is not included.
2. If it does detect that the user is signed on, it sends an ATTACH with the 
   AV bit set and the PV bits set to "already signed on". Again, a password
   is not included.
The most basic way to keep an APPC conversation secure is to send a user_id and password on each ATTACH, which can then be verified by the receiving LU. The problem with this is that the password is continuously passed in messages, increasing the likelihood of its being intercepted. PV and AV both provide a mechanism for reducing (or removing altogether) the number of messages that contain the password, and thereby improving security.

For AV the password is never sent on any ATTACH. The receiving LU trusts the sending LU to have done all of the security checking. If a receiving LU trusts a sending LU, the sending LU can avoid including the password on any ATTACH by setting the AV indicator bit instead. The AV bit tells the receiving LU that the sending LU has already verified the TP's credentials (by some private method) and the receiving LU does not have to worry about doing any checking itself.

For PV, the password is sent on the first ATTACH, and is never sent again. On the first ATTACH, the PV bit is set, and a password is included. This signals the receiving LU to check the password and then add the user_id to a list of users who do not need to be verified again. On the second and subsequent ATTACHes the PV bit is set, but no password is included. This signals the receiving TP that it just needs to check that the user is in the list of users it has verified in the past. 

Keywords          : kbbug3.00 kbbug3.00.sp1 prodsna snaappc snacpic snaprog snatp kbbug3.00.sp2 kbbuglist
Version           : WINDOWS:3.0,3.0SP1,3.0SP2
Platform          : WINDOWS
Issue type        : kbbug
Solution Type     : kbfix

================================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: February 11, 1998
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.