Microsoft KB Archive/248354
Article ID: 248354
Article Last Modified on 6/24/2004
- Microsoft SNA Server 4.0
- Microsoft SNA Server 3.0 Service Pack 2
- Microsoft SNA Server 3.0 Service Pack 3
- Microsoft SNA Server 3.0 Service Pack 4
- Microsoft SNA Server 4.0
- Microsoft SNA Server 4.0 Service Pack 1
- Microsoft SNA Server 4.0 Service Pack 2
- Microsoft SNA Server 4.0 Service Pack 3
This article was previously published under Q248354
NOTE: The information in this article applies only to Host Security Users who are configured for the Password is Replicated option in Host Account Manager (UDConfig.exe).
Although it's possible to change the service account password that the Host Security Services run under, a future problem may eventually occur for end-users who are configured to replicate their Windows NT password to an AS/400 user database (or a mainframe user database if third-party software is being used). This is described in the "More Information" section of this article.
When the Host Security service account password is changed, anytime an end-user changes their Windows NT password, the Event Viewer application log records the following two events:
If an SNA WinNT Account Synchronization trace (PMPINTx.ATF) was taken during the time of a failure, an error similar to the following occurs:
During the Host Security installation, the Setup program stores the Host Security service account name and password in the Local Security Authority (LSA). In addition to this, another service account copy is managed by the Service Configuration Manager (SCM). When the service account password is changed, the "new" service account password information is updated to the SCM; however, the one stored by the Setup program in the LSA is never updated.
To resolve this problem, contact Microsoft Product Support Services to obtain Lsainput.exe. Lsainput.exe synchronizes the LSA with the new service account password being used.
Because all Host Security Services store and retrieve the service account password from its own "local" LSA, Lsainput.exe needs to be run on any computer where a Host Security component (service) is installed so that every local/private LSA copy is updated.
For a complete list of Microsoft Product Support Services phone numbers and information on support costs, please go to the following address on the World Wide Web:
A temporary workaround is to change the service account password back to what it was before.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.
When Windows NT receives a password change, the request is intercepted by the SNA Password Change DLL (Snapwchg.dll). This DLL is responsible for coordinating the password change between Windows NT and host systems (AS/400 or mainframe). Because this DLL communicates with other Host Security components (services) through Remote Procedure Calls (RPC), an RPC request is issued to the SNA Password Management Process (SNAPMP). Because the LSA was never updated to reflect the "new" service account password change, the RPC request fails, and the Host Account Cache (HAC) does not get updated. If the HAC is never updated, the end-users' "new" Windows NT password change never gets to the AS/400 or host system user database.
It is important to understand that even though the HAC is not updated, the Windows NT user database is. From this point forward, the Windows NT user database is out of sync with the HAC and the host system database.
Although the Windows NT database is now out of sync with the HAC, applications written to take advantage of Single Sign-On (SSO) will continue to work as long as the host system allows the existing password access. It is here where the possibility for future failures might occur.
For example, if an AS/400 or host system enforces rules on user accounts (similar to account policies in Windows NT), at some point, the host password will expire. When this occurs, if an end-user attempts to synchronize their Windows NT Password with the host system, the HAC is never updated, and SSO then fails because the password on the host side has expired.
Keywords: kbbug kbfaq kbpending KB248354