MS RPC, EPMAPPER and MS Exchange

[casey at seattle.gii.net]

I recently joined this list because Im trying to add code to 
samba that will enable it to authenticate logins from MS Outlook 
clients that expect to login to an Exchange server. This is part of 
a larger effort to create an opensource replacement for MS 
back office applications. 

I've searched through the list archive and only found one reference 
to someone trying to use the samba rpc code to enable exchange 
logins but nothing substantial. Has anyone looked at this, and is 
it just vastly more complex than it appears ? 

When Outlook tries to login to an exchange server it tries to 
connect to the the RPC service on the exchange server through 
a named pipe /PIPE/EPMAPPER. 
After reading the support.ms.com and msdn.ms.com pages I suspect 
EPMAPPER ( the MS RPC EndPoint Mapper, maps services to port 
numbers )  tells outlook on which port to contact the Exchange 
server and I imagine the client is authenticated in the NT domain 
through this interface aswell. 

Outlook can be configured to make this request over tcp/ip to 
port 135 of the exchange server, which would probably make 
more sense than going through the filesystem on a samba server, 
but since a lot of the RPC code appears to be present in samba 
I would like to use this rather than implement the RPC code 
from scratch.  

http://support.microsoft.com/support/kb/articles/Q159/2/98.ASP 
documents the rpc trafffic between 2 Exchange servers and Im 
assuming the outlook client is doing somethign similar. 
Unfortunatly I dont have access to an Exchange server to sniff 
the traffic myself, so Id very much like this confirmed. 

To test this hypothesis I added a hook for EPMAPPER to 
smbd/ipc.c : named_pipe( .. ) 
where LANMAN and all the other names pipe commands are 
directed to api_reply( ) or api_fd_reply( ) and added an
 epmapper_reply( .. ) 
which basically just reports the command and goes to 
send_trans_reply( .. ).

This gives me an SMBopenX command which generates an error in 
smbd/pipes.c : reply_open_pipe_and_X( .. ) 

To get around this, I added an entry for EPMAPPER in 
rpc_parse/parse_rpc.c : pipe_names [ ] 

with an SYNT_EPMAPPER_V0 structure based on the UUID mentioned
in the Q159/2/98 article above for the End Point Mapper.

So far, Im getting: 
smbd/ipc.c  : reply_trans    trans <\PIPE\EPMAPPER> data=0 params=0 setup=2
			     its a pipe, so go to named_pipe( ) 
smbd/ipc.c  : named_pipe     initial command with setup = 83
smbd/pipes.c: reply_open_pipe_and_X( )  to open the pipe

smbd/ipc.c  : reply_trans    trans <\PIPE\> data=0 params=2 setup=2
			     now we can actually do something with it
smbd/ipc.c  : api_fd_reply   Got API command 0x1 on pipe "epmapper" 
			     0x01 = Set Named Pipe Handle state

smbd/ipc.c  : reply_trans    trans <\PIPE\> data=72 params=0 setup=2
smbd/ipc.c  : api_fd_reply   Got API command 0x26 on pipe "epmapper" 
			     0x26 = dce/rpc command 
rpc_server/srv_pipe.c
            : rpc_command    RPC_BIND .. call api_pipe_bind_req
                             bind \PIPE\epmapper to .. epmapper ? 

smbd/ipc.c  : reply_trans    trans <\PIPE\> data=164 params=0 setup=2
			     Got API command 0x26 on pipe "epmapper" 
rpc_server/srv_pipe.c 
        : rpc_command        RPC_REQUEST with 164 bytes of data 
	: api_pipe_request   an entry I added in  api_fd_commands
		    	     calls api_epmapper_rpc.
        : api_epmapper_rpc   
     According to the Q159/2/98 document we should get a request with 
     opnum 0x03 so I setup and entry in api_fd_commands so this calls 
     api_rpcTNP with a pointer to api_epmapper_cmds which has one 
     entry .. EPMAPPER_GETUUID for opnum 0x03 
	: api_epmapper_getuuid  

 Apparently this is the request for a port number based on a UUID.
Sure enough, in the 164 bytes of data, 16 of which look like the normal 
rpc header, there's a UUID 
   8A885D04 - 1CEB - 11C9 - 9F E8 08 00 2B 10 48 60
which would be the exchange server it's looking for, but so far I havent 
seen ANY documentation on the interpretation of the rest of the request 
or, for that matter, the reply. 

Is this an acceptable way to deal with the epmapper requests ? Has 
anyone else tried to provide similar functionality or researched the 
issue and maybe have information about the format of the RPC request 
packets to map a UUID to a port number ? 

Thanks,
Case van Rij