ncacn_http for 4.2? (Re: RPC over HTTP (ncacn_http) implementation for DCERPC client libraries)

Stefan (metze) Metzmacher metze at samba.org
Mon Aug 25 08:22:34 MDT 2014


Hi Samuel,

> I have made the captures on the RPC proxy machine, where you can see all
> the traffic flow. Let me summarize how the protocol works and the
> environment where I took the captures (I disabled TLS and RPC encryption).
>
> The goal of the RPC over HTTP protocol is to avoid opening RPC ports to
> internet and let the clients outside the internal lan to connect to it.
> The client opens a "RPC tunnel" over two HTTP connections (the channel
> in and channel out) to the RPC proxy server, and this machine forwards
> the RPC frames to the final RPC server. If the RPC proxy is behind a
> firewall or nat, only the ports 80 or 443 have to be opened and
> forwarded to it. The first step is to open the tunnel by exchanging some
> PDU's with the RPC proxy (see connection.jpg), after that the RPC frames
> are just pushed into the opened stream and the proxy forward them to the
> desired RPC server.
> 
> I have attached a diagram of the environment (network.pdf):
> 
> 1. The w2k8.kernevil.lan host is the domain controller and the desired
> RPC server the client wants to connect to (Exchange 2010). The IP
> address is 192.168.2.10.
> 
> 2. The cas.kernevil.lan is a domain member running the client access
> Exchange role (the RPC proxy), IP address is 192.168.2.20.
> 
> 3. This two servers are in a private network and behind NAT, the
> gateway/firewall IP is 192.168.2.254 and it forward the 80 and 443 ports
> to cas.kernevil.lan. It is also a DNS server authoritative for the
> 'kernevil.net' domain, because the client uses the external domain to
> connect to the RPC proxy.
> 
> 4. The client is openchange and is outside the lan. In the capture the
> client is listing the mailbox. The binding string is:
> 
> ncacn_http:w2k8.kernevil.lan[rpcproxy=cas.kernevil.net:80,]
> 
> The host cas.kernevil.net is resolved to the public address of the
> gateway, which forward ports 80 and 443 to the RPC proxy
> cas.kernevil.lan replacing the client source ip address.
> 
> Finally, answering your questions:
> 
> 1. The difference between 'rpc proxy' and 'http proxy':
> The RPC proxy is the HTTP connection endpoint (cas.kernevil.lan). This
> machine extract the RPC frames from HTTP body and forward them to the
> final RPC server (w2k8.kernevil.lan). The http proxy refers to the
> optional use of a http proxy in the client side, instead connecting
> directly to the RPC proxy.
> 
> 2. The relation between 'rpc proxy' and 'rpc server':
> The client wants to connect to the RPC server, but as it is not
> reachable because it is behind nat, opens a RPC tunnel over HTTP to the
> RPC proxy and the RPC proxy forwards RPC frames to the RPC server.
> 
> 3. The http proxy refers to the use of a http proxy in the client side.
> It is not yet implemented, so I don't have captures for this. At this
> point the implementation only supports direct connection to the HTTP
> server without proxies. There is a section in the specifications to
> handle this (section 3.2.2.4.1.1) and affects how the tunnel is opened.
> 
> If you need more captures just let me know.

I'll let you know :-)

Thanks for the information!

I briefly looked at the patches.
They basically look ok, but:

- Please avoid any changes to to struct dcerpc_binding,
  I think they are not needed. You can use any key=value option
  without a modification.

- I'm not 100% happy with the coding style and
  some missing talloc checks and other small details.

As OpenChange is the only consumer of this code,
what do others think?

Should we just import the ncacn_http support patches into master (before
4.2) and
I'll then fix coding style the the other details on top of it? This seems to
be faster as we don't have long review roundtrips.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140825/92adbeba/attachment.pgp>


More information about the samba-technical mailing list