RPC over HTTP (ncacn_http) implementation for DCERPC client libraries

[Stuart Naylor]

I don't really get the way you have the domain creation, DNS and proxy setup.

Firstly it forces the public DNS mydomain.wan and sets up samba on that.
Its better practise to have mysubdomain.mydomain.wan as this separates the AD domain and public domain.

Not being exactly sure about this but the bind implementation isn't correct. It doesn't seem to be setup correctly with isolated forward and reverse zones.

I think there is still legacy stuff in there. Also I find the internal DNS of samba a much better implementation.

I have been trying to offer other services over 80 & 443 and there is something screwy with the reverse proxy and its rewrite rules.

If I create vanilla samba it works in so many area's , in your package there is so much legacy stuff because of early adoption I always seem to have weird and wonderful problems.

I think if you created a vanilla samba install and bog standard DNS and ran up openchange with a reverse proxy it would probably work.

Stuart. 

 
 
-----Original message-----
> From:Samuel Cabrero <scabrero at zentyal.com>
> Sent: Wednesday 13th August 2014 19:51
> To: Stefan (metze) Metzmacher <metze at samba.org>; Julien Kerihuel <jkerihuel at zentyal.com>; samba-technical at lists.samba.org
> Subject: Re: RPC over HTTP (ncacn_http) implementation for DCERPC client libraries
> 
> Hi Stefan,
> 
> 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.
> 
> Thanks!
> 
> On 17/06/14 14:05, Stefan (metze) Metzmacher wrote:
> > Hi Julien,
> >
> >> Following our discussion at SambaXP about ncacn_http support addition to
> >> samba dcerpc client libraries, we have brought the changes we had been
> >> discussing about. You will find in attachment the patches required to
> >> enable RPC/HTTP support and have openchange client libraries working
> >> with Microsoft Exchange 2013.
> >>
> >> Zentyal is not retaining any copyright on this code. We are just looking
> >> forward merging it upstream. If you therefore need any specific
> >> agreement to be signed or if you need our developer to send a
> >> developer's certificate of origin, just let us know so we can move forward.
> >
> > See https://www.samba.org/samba/devel/copyright-policy.html,
> > if you have remaining questions just ask via contributing at samba.org.
> >
> > I've have a closer look at the changes in the next days/weeks,
> > but first I need to understand the protocol a bit more.
> >
> > - What is the difference between 'rpc proxy' and 'http proxy'?
> > - What is the relation between rpc proxy and rpc server?
> > - At which layers may use tls encryption?
> > - Can I get captures from a ncacn_http sessions:
> >    1.) without any proxy
> >       a) captured on the client
> >       b) captured on the server
> >    2.) with a rpc proxy
> >       a) captured on the client
> >       b) captured on the server
> >       c) captured on the rpc proxy (client side)
> >       d) captured on the rpc proxy (server side)
> >    3.) with a rpc proxy and a http proxy
> >       a) captured on the client
> >       b) captured on the server
> >       c) captured on the rpc proxy (client side)
> >       d) captured on the rpc proxy (server side)
> >       e) captured on the http proxy (client side)
> >       f) captured on the http proxy (server side)
> >
> > Thanks!
> > metze
> >
> 
> -- 
> Samuel Cabrero - Developer
> scabrero at zentyal.com
> 
> Zentyal - Active Exchange
> www.zentyal.com
>