Host Security Integration setup and architectural overview

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.

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:

1. 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.
2. 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.
3. 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.
4. 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.