Single Signon for APPC Applications Using Privileged Proxy

This article was previously published under Q165385
This article has been archived. It is offered "as is" and will no longer be updated.
An Advanced Program-to-Program Communications (APPC) application is not allowed to open an LU6.2 conversation using theMicrosoft SNA Server 3.0 Host Security single signon feature and impersonate thesecurity context of another Microsoft Windows NT user account.

An APPC application that is defined on a computer running Windows NT canonly open a conversation using single signon on behalf of the Windows NTaccount that the application is defined to use.
SNA Server 3.0 was not originally designed to support this functionality.
Several updates have been made to SNA Server 3.0 to allow a privileged APPCapplication to open an APPC conversation using the single signon feature onbehalf of any defined Windows NT user. This is theprivileged proxy feature. In addition, an extension has been added to theAPPC API to invoke the feature. These extensions are documented in thedescriptions of [MC_]ALLOCATE APPC verbs.

An APPC application becomes privileged when the application is started in a Windows NTuser account that is a member of a special Windows NT group.

When a Host Security Domain is configured, SNA Server Manager defines asecond Windows NT group for use with the host security features of SNAServer. If the user account under which the actual client is running is amember of this second Windows NT group, the client is privileged toinitiate an APPC conversation on behalf of any user account defined in theHost Account Cache.

The following illustrates how the privileged proxy feature works:

The SNA Server administrator creates a Host Security Domain called APP. SNAServer Manager now creates two Windows NT groups. The first group is calledAPP and the second is called APP_PROXY for this example. Users that areassigned to the APP group are enabled for single signon. Users assigned tothe APP_PROXY group are privileged proxies. The administrator adds theWindows NT user AppcUser to the APP_PROXY group using the Users button onthe Host Security Domain Property dialog box in SNA Server Manager.

The administrator then sets up an APPC application on the SNA Server to runas a Windows NT service called APPCAPP and that service is set up tooperate under the AppcUser user account. When APPCAPP runs, it opens anAPPC session via an MC_ALLOCATE verb using the extended VCB format andspecifies the Windows NT username of the desired user, UserA (for example).The SNA Server service sees the session request coming from a connectionthat is a member of the Host Security Domain APP. The Client/Serverinterface tells the SNA Server service that the actual client is AppcUser.The SNA Server service checks to see if AppcUser is a member of theAPP_PROXY group. Because AppcUser is a member of APP_PROXY, the SNA Serverservice inserts the Username/Password for UserA in the APPC Attach (FMH-5)command and sends it off to the partner TP.

APPC Application Requirements to Implement Privileged Proxy Support

In order to support the priviledged proxy feature, the APPCapplication must implement the following program logic:
  1. First, the updated Winappc.h and Wappc32.lib files must be used from the SNA Server 3.0 Service Pack 1 software development kit (SDK). The updated Winappc.h includes new prototypes to support the privileged proxy feature.
  2. The APPC application must determine the Windows NT user ID and domain name that it wishes to impersonate.
  3. The APPC application must set the following parameters before calling the [MC_]ALLOCATE verb:
    • Enable the use of the extended ALLOCATE verb control block (VCB) structure by setting the AP_EXTD_VCB flag in the opext field.
    • Set up the pointers for proxy_user and proxy_domain to point to UNICODE strings containing the user name and domain name of the user to be impersonated.
NOTE: The application does not need to set up user_id and pwd fieldsin the Allocate VCB.

When the APPC application performs the above steps and calls[MC_]ALLOCATE, the SNA Server performs a lookup in the hostsecurity domain for the specified Windows NT user, and sets theuser ID and password fields in the FMH-5 Attach message sent tothe remote system.
Microsoft has confirmed that this is a problem in SNA Server version 3.0. This problem was corrected in the latest Microsoft SNA Server 3.0 U.S.Service Pack. For information on obtaining the service pack, query onthe following word in the Microsoft Knowledge Base (without the spaces):
   S E R V P A C K				

Article ID: 165385 - Last Review: 10/04/2013 21:26:18 - Revision: 3.3

  • Microsoft SNA Server 3.0 Service Pack 4
  • kbnosurvey kbarchive kbbug kbfix kbnetwork kbprogramming KB165385