DCERPC requirements for DFS-R

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

DCERPC requirements for DFS-R

Samba - samba-technical mailing list
Hi,

We've been asked to look into SYSVOL replication and I'm aware that our
current DCERPC infrastructure is insufficient, but I haven't got a good
understanding of exactly what this entails. In particular, I was
wondering if these requirements would be diminished at all if we only
supported the initial sync. Just supporting the initial sync appears
simplify a number of the ACL problems that we currently encounter
(because we can pass through Samba and do our mappings) and seems to be
a reasonable partial step towards implementing the overall protocol. Any
ongoing replication could be made ad-hoc (with whatever mechanisms are
currently being used), until the time we choose to implement the remainder.

Matthieu had at one point, a simple client to do the initial sync, so
part of the work there is resolved and/or known. The question is the
corresponding server functionality.


Cheers,

Garming


Reply | Threaded
Open this post in threaded view
|

Re: DCERPC requirements for DFS-R

Samba - samba-technical mailing list
On Wed, Sep 06, 2017 at 12:01:01PM +1200, Garming Sam via samba-technical wrote:

> Hi,
>
> We've been asked to look into SYSVOL replication and I'm aware that
> our current DCERPC infrastructure is insufficient, but I haven't got
> a good understanding of exactly what this entails. In particular, I
> was wondering if these requirements would be diminished at all if we
> only supported the initial sync. Just supporting the initial sync
> appears simplify a number of the ACL problems that we currently
> encounter (because we can pass through Samba and do our mappings)
> and seems to be a reasonable partial step towards implementing the
> overall protocol. Any ongoing replication could be made ad-hoc (with
> whatever mechanisms are currently being used), until the time we
> choose to implement the remainder.
>
> Matthieu had at one point, a simple client to do the initial sync,
> so part of the work there is resolved and/or known. The question is
> the corresponding server functionality.

Can you point me at the client code just so I can take a quick
look ?

Reply | Threaded
Open this post in threaded view
|

Re: DCERPC requirements for DFS-R

Samba - samba-technical mailing list
Mentioned here:

https://lists.samba.org/archive/samba-technical/2014-October/102737.html


On 07/09/17 08:48, Jeremy Allison wrote:

> On Wed, Sep 06, 2017 at 12:01:01PM +1200, Garming Sam via samba-technical wrote:
>> Hi,
>>
>> We've been asked to look into SYSVOL replication and I'm aware that
>> our current DCERPC infrastructure is insufficient, but I haven't got
>> a good understanding of exactly what this entails. In particular, I
>> was wondering if these requirements would be diminished at all if we
>> only supported the initial sync. Just supporting the initial sync
>> appears simplify a number of the ACL problems that we currently
>> encounter (because we can pass through Samba and do our mappings)
>> and seems to be a reasonable partial step towards implementing the
>> overall protocol. Any ongoing replication could be made ad-hoc (with
>> whatever mechanisms are currently being used), until the time we
>> choose to implement the remainder.
>>
>> Matthieu had at one point, a simple client to do the initial sync,
>> so part of the work there is resolved and/or known. The question is
>> the corresponding server functionality.
> Can you point me at the client code just so I can take a quick
> look ?


Reply | Threaded
Open this post in threaded view
|

Re: DCERPC requirements for DFS-R

Samba - samba-technical mailing list
Am 06.09.2017 um 23:40 schrieb Garming Sam:
> Mentioned here:
>
> https://lists.samba.org/archive/samba-technical/2014-October/102737.html

The current code is here:

https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-dfs-r

I'll reply more detailed in the next days. (If not ping me again :-)

metze

> On 07/09/17 08:48, Jeremy Allison wrote:
>> On Wed, Sep 06, 2017 at 12:01:01PM +1200, Garming Sam via
>> samba-technical wrote:
>>> Hi,
>>>
>>> We've been asked to look into SYSVOL replication and I'm aware that
>>> our current DCERPC infrastructure is insufficient, but I haven't got
>>> a good understanding of exactly what this entails. In particular, I
>>> was wondering if these requirements would be diminished at all if we
>>> only supported the initial sync. Just supporting the initial sync
>>> appears simplify a number of the ACL problems that we currently
>>> encounter (because we can pass through Samba and do our mappings)
>>> and seems to be a reasonable partial step towards implementing the
>>> overall protocol. Any ongoing replication could be made ad-hoc (with
>>> whatever mechanisms are currently being used), until the time we
>>> choose to implement the remainder.
>>>
>>> Matthieu had at one point, a simple client to do the initial sync,
>>> so part of the work there is resolved and/or known. The question is
>>> the corresponding server functionality.
>> Can you point me at the client code just so I can take a quick
>> look ?
>


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DCERPC requirements for DFS-R

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
Hi,

I am also interested on this because I have started to work on
implement the missing parts on the initial Matthieu's work to get a
working client for the general case, not only for sysvol (multiple
content sets per replica group and arbitrary replication topology) [1].

I am working on top of current master and I haven't found any problem
related to DCERPC, so is it insufficient only for the server side but
enough for the client?

[1] https://github.com/kernevil/samba/tree/dfs-r

On Thu, 2017-09-07 at 09:40 +1200, Garming Sam via samba-technical
wrote:

> Mentioned here:
>
> https://lists.samba.org/archive/samba-technical/2014-October/102737.h
> tml
>
>
> On 07/09/17 08:48, Jeremy Allison wrote:
> > On Wed, Sep 06, 2017 at 12:01:01PM +1200, Garming Sam via samba-
> > technical wrote:
> > > Hi,
> > >
> > > We've been asked to look into SYSVOL replication and I'm aware
> > > that
> > > our current DCERPC infrastructure is insufficient, but I haven't
> > > got
> > > a good understanding of exactly what this entails. In particular,
> > > I
> > > was wondering if these requirements would be diminished at all if
> > > we
> > > only supported the initial sync. Just supporting the initial sync
> > > appears simplify a number of the ACL problems that we currently
> > > encounter (because we can pass through Samba and do our mappings)
> > > and seems to be a reasonable partial step towards implementing
> > > the
> > > overall protocol. Any ongoing replication could be made ad-hoc
> > > (with
> > > whatever mechanisms are currently being used), until the time we
> > > choose to implement the remainder.
> > >
> > > Matthieu had at one point, a simple client to do the initial
> > > sync,
> > > so part of the work there is resolved and/or known. The question
> > > is
> > > the corresponding server functionality.
> >
> > Can you point me at the client code just so I can take a quick
> > look ?
>

Reply | Threaded
Open this post in threaded view
|

Re: DCERPC requirements for DFS-R

Samba - samba-technical mailing list
Hi Samuel,

> I am also interested on this because I have started to work on
> implement the missing parts on the initial Matthieu's work to get a
> working client for the general case, not only for sysvol (multiple
> content sets per replica group and arbitrary replication topology) [1].
>
> I am working on top of current master and I haven't found any problem
> related to DCERPC, so is it insufficient only for the server side but
> enough for the client?
>
> [1] https://github.com/kernevil/samba/tree/dfs-r
I guess you may get away with RawGetFileData() instead of
RawGetFileDataAsync() as a client. But I'm not sure if it's possible
to trigger a fallback in the windows servers client side.

metze


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DCERPC requirements for DFS-R

Samba - samba-technical mailing list
On Thu, 2017-09-07 at 11:57 +0200, Stefan Metzmacher via samba-
technical wrote:

> Hi Samuel,
>
> > I am also interested on this because I have started to work on
> > implement the missing parts on the initial Matthieu's work to get a
> > working client for the general case, not only for sysvol (multiple
> > content sets per replica group and arbitrary replication topology)
> > [1].
> >
> > I am working on top of current master and I haven't found any
> > problem
> > related to DCERPC, so is it insufficient only for the server side
> > but
> > enough for the client?
> >
> > [1] https://github.com/kernevil/samba/tree/dfs-r
>
> I guess you may get away with RawGetFileData() instead of
> RawGetFileDataAsync() as a client. But I'm not sure if it's possible
> to trigger a fallback in the windows servers client side.
>
> metze
>

Hi Metze,

I think we are talking about the asynchronous RPC byte pipes. The
RawGetFileDataAsync is is implemented in protocol version 0x00050002
(LONGHORN | W2K8), so setting upstreamProtocolVersion to 0x00050000
(W2K3R2) on the EstablishConnection response will force the windows
client side to also use RawGetFileData. I have verified this with
network captures between a windows server 2003 R2 and windows server
2008 R2.

Samuel

Reply | Threaded
Open this post in threaded view
|

Re: DCERPC requirements for DFS-R

Samba - samba-technical mailing list
That all sounds very promising for an intermediate Samba-to-Samba
solution still within the protocol spec. That would be far better than
what we have right now. Though, have you checked if Windows 2016 still
supports this mode? I assume they would, given FRS was only just
deprecated in their latest service-pack type release.


Cheers,

Garming


On 08/09/17 06:22, Samuel Cabrero wrote:

> On Thu, 2017-09-07 at 11:57 +0200, Stefan Metzmacher via samba-
> technical wrote:
>> Hi Samuel,
>>
>>> I am also interested on this because I have started to work on
>>> implement the missing parts on the initial Matthieu's work to get a
>>> working client for the general case, not only for sysvol (multiple
>>> content sets per replica group and arbitrary replication topology)
>>> [1].
>>>
>>> I am working on top of current master and I haven't found any
>>> problem
>>> related to DCERPC, so is it insufficient only for the server side
>>> but
>>> enough for the client?
>>>
>>> [1] https://github.com/kernevil/samba/tree/dfs-r
>> I guess you may get away with RawGetFileData() instead of
>> RawGetFileDataAsync() as a client. But I'm not sure if it's possible
>> to trigger a fallback in the windows servers client side.
>>
>> metze
>>
> Hi Metze,
>
> I think we are talking about the asynchronous RPC byte pipes. The
> RawGetFileDataAsync is is implemented in protocol version 0x00050002
> (LONGHORN | W2K8), so setting upstreamProtocolVersion to 0x00050000
> (W2K3R2) on the EstablishConnection response will force the windows
> client side to also use RawGetFileData. I have verified this with
> network captures between a windows server 2003 R2 and windows server
> 2008 R2.
>
> Samuel