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

Mon Sep 1 02:03:27 MDT 2014

Hi Andrew, metze,

I have updated the copyright stuff for the new files and I have no 
problem if you modify the patches before pushing them.

I agree NTLM should be used instead Basic and as I will continue working 
on this I will send a patch for it.

Samuel.

On 26/08/14 06:07, Andrew Bartlett wrote:
> On Mon, 2014-08-25 at 16:22 +0200, Stefan (metze) Metzmacher wrote:
>> 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.
>
> I think this is a good approach in this situation.  The only thing to
> sort out first is the licence.  Julien indicated that Samual was keeping
> copyright, if so please get the statement updated (and Samual should
> keep some clear documentation of that personally), otherwise if it rests
> with Zentyal then change it to the LGPLv3 licence.
>
>  From my side, I would like to see it forced to use NTLMSSP or Kerberos,
> not Basic auth, particularly as Samba doesn't do SSL certificate
> validation (we, probably incorrectly, didn't think it was any use inside
> the network for LDAP, but HTTP over the web is a different risk
> profile).
>
> But in short, if this helps OpenChange, then I'm pretty keen to get it
> in.
>
> Andrew Bartlett
>

-- 
Samuel Cabrero - Developer
scabrero at zentyal.com

Zentyal - Active Exchange
www.zentyal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-Add-no-memory-checks.patch
Type: text/x-patch
Size: 2475 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140901/ed8aa8b3/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-Fix-crash-when-server-address-can-not-be-resolved.patch
Type: text/x-patch
Size: 1923 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140901/ed8aa8b3/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-DCERPC-pipe-open-over-ncacn_http-transport.patch
Type: text/x-patch
Size: 7680 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140901/ed8aa8b3/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Client-implementation.patch
Type: text/x-patch
Size: 65834 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140901/ed8aa8b3/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Add-http-library.patch
Type: text/x-patch
Size: 26384 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140901/ed8aa8b3/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Case-insensitive-comparision-of-binding-string-optio.patch
Type: text/x-patch
Size: 793 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140901/ed8aa8b3/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Remove-trailing-comma-from-last-binding-string-optio.patch
Type: text/x-patch
Size: 862 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140901/ed8aa8b3/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-binding-options-for-ncacn_http-transport.patch
Type: text/x-patch
Size: 4305 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140901/ed8aa8b3/attachment-0007.bin>