This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

December 1998

Microsoft Systems Journal Homepage

Windows NT Security on Unix

Since the Windows NT domain controller is not ported to Unix, COM on Unix supports Windows NT Lan Manager (NTLM) security using a passthrough system consisting of several support components. It's important to keep in mind that this modification to NTLM does not affect your development. You still implement NTLM security the same way for COM on Unix as you do for COM on Windows NT. COM on Unix just routes the authentication requests back to the domain controller on Windows NT. The passthrough system (forwarding authentication requests between the server on Unix and the domain controller on Windows NT) is opaque to the client.
The Windows NT domain controller, the client, and the server all participate in NTLM security. On Windows NT, the client initiates the authentication by calling the server on Windows NT. The server then negotiates with the client and the Windows NT domain controller to process the authentication request.
On Unix, there is an extra step to the authentication. The client (on Windows NT) initiates the call (using DCOM, as usual). The server application (on Unix) hosts the NTLM passthrough security system and negotiates with the Windows NT domain controller, which performs the authentication.
When a client requests authentication, the server uses a component called the NTLM Security Support Provider (SSP) to authenticate the client. The SSP negotiates the authentication level and calls another component called the Local Security Authority (LSA) to authenticate the client. Since the LSA runs only on Windows NT, the calls are forwarded to the Private Authentication Layer Daemon (PAULAD) that Microsoft provides as part of the COM sources. The PAULAD service forwards the request to the Windows NT domain controller by calling the Private Authentication Layer Service (PAULAS) on the domain controller. The forwarded request is sent over an encrypted RPC channel. The PAULAS service on the Windows NT domain controller processes login or challenge/response requests, and routes the results back through the passthrough system to the client.
 

COMTI Interoperability Details

The details of COMTI's integration with IBM mainframes is a good example of the cooperation required by both platform vendors so their products can interoperate. Let's go over how COMTI talks to an IBM mainframe so you get a better idea of the low-level protocol coordination required for interoperability.
The COMTI for IMS and CICS is a component of Microsoft SNA Server 4.0 that allows your COM and MTS components to participate in CICS and IMS transactions. Before I talk about what COMTI does, I'll go over the acronym-laden terms:

  • CICS is the IBM Customer Information Control System, a transaction manager that supports distributed online transaction processing and uses the APPC/LU 6.2 protocol to talk with other systems.
  • IMS is IBM's Information Management System for data processing.
  • The CICS or IMS transaction program (TP) provides access to the mainframe database and may implement some business logic.
  • Logical unit LU 6.2 is an IBM protocol that guarantees compatibility between programs across a network or on the same system.
  • SNA Server accesses LU through the Advanced Program-to-Program Communication (APPC) API.
For a TP to communicate directly with another TP system using APPC, the two programs must set up an LU 6.2 connection. IBM uses LU 6.2 for distributed transaction processing. COMTI, which also uses LU 6.2, provides a bridge for MS DTC to communicate with an IBM MVS. This means that MTS components can get data and participate in transactions from IBM mainframes running under IMS and CICS.
The COMTI runtime proxy translates method invocations from a COMTI component into messages that the mainframe application can process. The runtime proxy then turns the data that the mainframe application returns into something that the COMTI component can interpret and pass on to the MTS component. Not only does the runtime proxy pass comprehensible messages between COM or MTS components and the mainframe, it also maps the relationship between OLE Automation and COBOL data types.
Clearly, providing interoperability between platforms takes a solid understanding of protocols and a creative bent towards mapping platform specifics.