Article ID: 222121
Article Last Modified on 10/31/2003
APPLIES TO
- Microsoft SNA Server 4.0
This article was previously published under Q222121
SYMPTOMS
When an APPC or CPIC application initially allocates a conversation over an LU6.2 session (where the remote system supports persistent verification, or "PV"), SNA Server stores the user ID in an internal PV signed-on list, sets the "PV sign-on requested" bit, and sends the user ID and password in the FMH-5 Attach request to the host. When the same user attempts to allocate further conversations over the PV-enabled session, SNA Server sets the PV "already signed on" bit and the user ID in the FMH-5 Attach. But, SNA Server never verifies if the user password provided in subsequent conversation attempts matches the initial user password.
See the "More Information" section below for a description of SNA Server behavior when the update is applied.
CAUSE
The IBM Persistent Verification specification appears to assume that the password provided on subsequent conversation requests for a given user is the same as the initial password provided by the user.
RESOLUTION
SNA Server 4.0
To resolve this problem, obtain the latest service pack for SNA Server version 4.0. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
215838 How to Obtain the Latest SNA Server Version 4.0 Service Pack
SNA Server 3.0
To resolve this problem, obtain the latest service pack for SNA Server version 3.0. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
184307 How to Obtain the Latest SNA Server Version 3.0 Service Pack
STATUS
Microsoft has confirmed that this is a problem in SNA Server 3.0 SP3, 4.0, 4.0 SP1 and 4.0 SP2. This problem was first corrected in SNA Server version 3.0 Service Pack 4 and SNA Server version 4.0 Service Pack 3.
MORE INFORMATION
With this update applied, SNA Server now caches the initial password provided by the user when the PV sign-on request occurs. On subsequent conversation requests from the same user, SNA Server verifies that the password matches the initially supplied password. If the passwords don't match, SNA Server no longer passes the user's conversation request over a PV-enabled session. Instead, SNA Server passes the user ID and password to the host for validation. In other words, if SNA Server suspects that an invalid password was provided, SNA Server does not indicate the use of persistent verification, and forces the host to reverify the request. When this occurs, SNA Server logs the following event to the Windows NT application event log:
Event ID: 63
Source: SNA Server
Description: Incorrect password received from client for logged on user
EXPLANATION
An invalid password was specified for a signed-on PV user (user ID: user).
This password will be forwarded to the host to verify. If the password has changed, then the host wil accept the new password, and the conversation will continue without persistent verification.
ACTION
If host rejects password, then check password, and try again.
If this event occurs, the user still exists in the SNA Server PV signed-on list with the initially supplied password. If the user supplies a password that matches the initially supplied password, then the PV-enabled session is used. However, if the same user supplies a different password, SNA Server sends the user ID and password to the host but does not use PV.
Note that a user is only removed from the SNA Server PV signed-on list if:
- The remote system sends a Sign-Off GDS request to SNA Server. -or-
- The LU-LU session limits drop to zero.
For more information about persistent verification, see the following IBM reference:
SNA LU6.2 Peer Protocols, Section 1.3.2.3: Persistent Verification
IBM Document #SC31-6808
Keywords: kbbug kbfix kbsna300sp4fix kbsna400sp3fix kbqfe KB222121
