Host Security Integration setup and architectural overview (175063)
The information in this article applies to:
- Microsoft SNA Server 3.0
- Microsoft SNA Server 4.0
This article was previously published under Q175063 SUMMARY
Host Security Integration contains three installable components which are
not installed by default when installing SNA Server. They include:
- SNA Host Account Synchronization Service: SNAHOSTPROCESS
- Windows Password Synchronization Service: SNAPMP
- Host Account Cache Service: SNADATABASE
All three components work together providing features such as Account
Mapping, Password Synchronization, and Automatic Logon which is also
referred to as Single Sign-On (SSO) support. The implementation of your
Windows Domains determines where each component (service) resides.
Certain components must be installed on certain systems as indicated
below. Microsoft recommends that all three components be installed
regardless of if you don't plan on using a particular component, due
to the way these services register themselves with the other
components. It is also recommended that all services are installed in
the same user security administrator's account.
MORE INFORMATION
SNAHOSTPROCESS
The SNA Host Account Synchronization Service, also known as
SNAHOSTPROCESS, is responsible for automatic password synchronization
and security between Windows and IBM host or AS/400 systems. Although
this service is not dependent on the SNA protocol, it is recommended
that this service be installed on SNA Server computers. SNAHOSTPROCESS
is installed if the Host Security Integration option is selected while
installing SNA Server.
SNAHOSTPROCESS is responsible for propagating password changes to the
host and for receiving password changes from it. When a Windows
password changes, SNAPMP coordinates with SNAHOSTPROCESS to apply
these changes to the Host. Similarly, password changes received from
the Host by SNAHOSTPROCESS are forwarded to SNAPMP for appropriate
distribution. The SEC400.DLL included with SNA Server 3.0 applies
Windows password changes to AS/400 systems running OS/400 V3R1
or later. For password changes coming from an AS/400, Host Code is
required from a third-party vendor such as ExecuSoft, Inc. The
SNAHOSTPROCESS also supports RACF V2R2, Computer Associates
International CA-Top Secret (MVS, VM, VSE) and ACF2 (MVS) Security
systems on IBM Mainframes. The Security Integration DLLs and Host
Code for those security systems are available from Proginet Inc.
Proginet supports automatic password synchronization using LU6.2
protocol to communicate with IBM Mainframe systems. See the Companion
Products Catalog on the SNA Server CD for additional references.
SNAPMP
The Windows Password Synchronization Service is responsible for
synchronizing passwords between a host and the Windows domain. It
then coordinates all updates to the Host Account Cache (SNADATABASE).
The Snapwchg.dll is responsible for intercepting password changes made
to Windows accounts in its Windows Domain and passing them on to
SNAPMP. The Master Windows Password Synchronization Service must be
installed on the primary domain controller of the Windows domain in
which the user accounts are defined. At any given time there should be
only 1 Master PMP in the whole Host Security Setup (across multiple
domains).
The Windows Password Synchronization Service is installed using the
Setup program located in the \HOSTSEC directory on the SNA Server CD.
SNADATABASE
The Host Account Cache implements a database of host accounts associated
with Windows Domain Accounts. The SNADATABASE receives updates from
SNAPMP by using RPC calls which are then sent to any backup SNADATABASE's
that are running in the Host Security Domain.
The SNADATABASE service must be installed on a Primary Domain Controller
and a Backup Role can be chosen which would be installed on Windows
Backup Domain Controllers that belong to the same SNA Server Windows
Domain.
The SNAPMP and SNADATABASE components must be installed on computers
running Windows Domain Controllers, but unlike Security Integration
Service (SNAHOSTPROCESS), these components can be installed on computers
not running SNA Server. For this reason, these components are installed
using a separate setup program located in the HOSTSEC folder of each
Windows platform on the SNA Server CD.
Creating a Host Security Domain (HSD)
After all three services are installed; a Host Security Domain must be
configured. Although this process can be completed by using the Insert
menu in Manager, using the Host Security Domain Wizard from the Tools
menu is a much simpler process, since multiple configuration steps are
performed automatically. Using the Host Security Domain Wizard:
- Provide a name for the host security domain.
For simplicity, the name should reflect the name of the remote system
where the user accounts reside. For example, if the AS/400 name is
"RAINIER", use the name "RAINIER". If the remote system is a RACF on
host system MVS1, then use the name "MVS1RACF".
Using the wizard, the name given during this process creates a Local
Group in the Windows Domain, which by default will contain the
Domain Users global group. The Domain Users group must be added in
order for users to participate in a Security Domain.
- Provide the connection name and account mapping method to be used.
Enter the connection name that will be used for this Host Security
Domain, followed by the "User Name Mapping". Enable automatic password
synchronization is the next option that can be selected. Automatic
password synchronization requires a Security Integration DLL which must
be chosen from the drop down box.
- Choose the Local and Remote APPC LU's to use on this connection.
You will then go on to select your Local and Remote APPC LU pairings
used for this defined connection.
- Configure users in the host account cache.
The last and final step of this process is to configure the Host Account
Cache. This is done by going into the Tools menu in SNA Server
Manager and selecting Host Account Manager. The Host Account Configuration
dialog is displayed and you can then configure your users appropriately.
You must first select a User Account from the Windows Database. Select
Use Windows User Name or Use This User ID. Use Windows Password or
Use This Password also must be selected.
Single-Signon Support
Sample operation of single-signon with an APPC or CPIC application:
- APPC application calls [MC_]ALLOCATE and requests security=AP_PGM or
AP_SAME, and sets the user_id=MS$SAME, and pwd=MS$SAME. The SNA Server
APPC DLL then forwards the Allocate request to SNA Server.
- If a CPIC application is used, the conversation security, userid and
password fields must be set using the Set_Conversation_Security_Type
(cmscst, setting conversation_security_type = CM_SECURITY_PROGRAM or
CM_SECURITY_SAME), Set_Conversation_Security_Password (cmscsp, setting
security_password = MS$SAME), and Set_Conversation_Security_User_ID
(cmscsu, setting security_user_ID = MS$SAME), before calling
Allocate_Conversation (cmallc).
- The SNA Server checks if the Windows user making this request is a
member of the host security domain. If so, the host security account
information is looked up for the user and replaced in the userid and
password fields in the FMH-5 Attach message, and then is sent to the
remote system.
Sample operation of single-signon with a 3270 application (supported
with SNA 3.0 SP1 and later):
- First, the 3270 emulator must support "scripting" of user input.
- The user or administrator must record a script for the user, capturing
the host logon process. At the host logon screen, the user or
administrator must enter the following values for the host user id =
MS$SAMEU and password = MS$SAMEP.
- When the 3270 emulator starts up (configured to automaticaly run the
scripted logon), the above MS$SAMEU and MS$SAMEP is passed to the SNA
Server.
- The SNA Server checks if the Windows user making this request is a
member of the host security domain. If so, the host security account
information is looked up for the user and replaced in the userid and
password fields in the host signon screen, and then is sent to the
remote system.
Modification Type: | Major | Last Reviewed: | 10/12/2004 |
---|
Keywords: | kbinfo kbnetwork KB175063 kbAudDeveloper |
---|
|