The MS$Same value is passed as the user name and as the password in Host Integration Server 2004

In Microsoft Host Integration Server 2004, when you activate a Transaction Integrator (TI) Windows-initiated processing (WIP) component that is configured to use the explicit security callback routine, the activation is not successful. Additionally, the mainframe reports a security violation.

Event ID 401 is logged in the Application log. Event ID 401 indicates that the mainframe rejected the attempt to connect because of a security failure. A review of a Data Link Control trace to the mainframe shows that the MS$SAME value is passed as the user name and as the password.

This behavior occurs when null values are returned from the explicit security callback routine.

To resolve this behavior, use the context array to pass credentials instead of using the explicit security callback routine. Alternatively, review the custom code that returns credentials to the TI client program. Additionally, you may find it helpful to review the code in Microsoft Visual Studio or to use some other method to capture what is returned on the call to the security package.

This behavior is by design.

For more information about the context array, click the following article numbers to view the articles in the Microsoft Knowledge Base: For more information about how to use the context array, see the "COMTIContext Interface" section of the Transaction Integrator Programmer's Reference. The Transaction Integrator Programmer's Reference is available in the Host Integration Server 2004 documentation under SDK.

To confirm that you are experiencing this behavior, create a trace by using TI WIP internal tracing on the Host Integration Server 2004 computer. Additionally, create a Data Link Control trace on the Host Integration Server 2004 computer. Use the traces to verify the data that is passed in the ATTACH request to the mainframe. Additionally, use the traces to determine whether the explicit security callback routine successfully completed.

Note the difference between the two trace log examples. Although the successful callback and the unsuccessful callback show the words "security callback succeeded," you must search for two more lines that contain the following information:

�	When the callback is successful, the line that ends with the words "security callback succeeded" is followed by two lines that end with the words "got userid" and "got pswd." The presence of these two lines confirms that the callback is successful.
�	When the callback is not successful, the lines that end with the words "got userid" and "got pswd" are not present. The absence of these two lines indicates that the values that are returned by the callback are not valid.

The following trace log example is an example of a successful callback from a TI WIP trace log:

	3588 00000e80 Nov 12 17:23:50.562	14040	LU 6.2 Transport Connect explicit security callback succeeded.
	3588 00000e80 Nov 12 17:23:50.562	14040	LU 6.2 Transport Connect got userid. 
	3588 00000e80 Nov 12 17:23:50.562	14040	LU 6.2 Transport Connect got pswd. 
	3588 00000e80 Nov 12 17:23:50.562	14040	LU 6.2 Transport Connect Using Non-link model RemoteTp=XXXX.

The following trace log example is an example of an unsuccessful callback from a TI WIP trace log:

	3588 00000d5c Nov 12 17:30:56.328	14040	LU 6.2 Transport Connect explicit security callback succeeded. 
	3588 00000d5c Nov 12 17:30:56.328	14040	LU 6.2 Transport Connect Using Non-link model RemoteTp=XXXX.

Sample Systems Network Architecture trace data

The ATTACH request in the following Data Link Control trace shows that the MS$SAME value is passed to the host as the user name and as the password.

	---- Element at address 024E1B68, start 10, end 268 
	
	0B912040 0502FF00 03D10000 08C3E2E2     <j @.....J...CSS>
	
	E3C1F0F2 7C120802 D4E25BE2 C1D4C508     <TAXX|...MS[SAME.>
	
	01D4E25B E2C1D4C5 1910E5C5 D9C9E9D6     <.MS[SAME..

This code example is followed by a response from the host that clearly indicates a security violation.

	  ---- Element at address 024E2918, start 10, end 161 ----
	0B810107 07080F60 5180008E 12E10010     <.a.....`Q.......>
	0E10000B 11040806 A961D6E2 4040007A     <........zaOS@@.z>
	C1E3C2F7 F0F0F1F7 C940E3D7 40A28583     <xxxxxxxxx@TP@sec>
	A49989A3 A840A589 969381A3 8996954B     <urity@violationK>
	4040D781 99A39585 9940D3E4 40E2C1C1     <@@Partner@LU@XXX>
	C9D4E2C1 F8409985 918583A3 858440A3     <XXXXX@rejected@t>
	88854081 93939683 81A38540 998598A4     <he@allocate@requ>
	85A2A340 82858381 A4A28540 81A4A388     <est@because@auth>
	969989A9 81A38996 95408388 858392A2     <orization@checks>
	0868189 9385844B                        <@failedK        >

The following Function Management Header 7 (FMH7) code example includes the sense data "080F 6051" in the last line. According to the formats guide and to the Advanced Program-to-Program Communications (APPC) reference manual, this sense data indicates the following.

	Secondary Return Code = 080F6051 (AP_SECURITY_NOT_VALID)

	----------------------------------------------- 17:30:56.0812
	01020DB2->1F000007 LU 6.2   
	          MSGID:RDAT   MSGTYP:FMH7   
	
	---- Header  at address 01AF54C0, 1 elements ----
	01070000 0000003C 05000000 01002805     <.......<......(.>
	   
	---- Element at address 024E3480, start 13, end 19 ----
	0707080F 605180 <....`Q. >

Event ID 401 in the Application log

The following TI WIP trace log shows event ID 401 that was logged in the Application log:

	3588 00000d5c Nov 12 17:30:56.812	14066	LU 6.2 Transport ReceiveAndWait Error log data=ATB700XXX TP security violation.
	  Partner LU XXXXXXXX rejected the allocate request because authorization checks failed.
	3588 00000d5c Nov 12 17:30:56.812	10003	Logging system warning event, ID=401. 
	3588 00000d5c Nov 12 17:30:56.828	14065	LU 6.2 Transport ReceiveAndWait Exit Error DISP_E_EXCEPTION.