s4: fsmo role transfer
nivanova at samba.org
Thu Sep 9 07:03:02 MDT 2010
Hi Tridge and Andrew,
Thank you for reviewing and fixing the code! Also thanks to Anatoliy who
picked up where I left off and debugged and tested it. You are right about
the lack of acl protection. For the time being we will add a check for
SECURITY_DOMAIN_CONTROLLER. The proper way is to check for a few access
control rights when the LDAP request is received, and another set of CARs in
getncchanges, I'll take care of that.
On Thu, Sep 9, 2010 at 1:13 PM, Anatoliy Atanasov <
anatoliy.atanasov at postpath.com> wrote:
> Hi Tridge,
> > > Hi Nadya,
> > Andrew and I looked over your FSMO role transfer patches today. Very
> > nice work! You are producing some great code.
> > Andrew spotted one thing, which is that the rootdse role transfers
> > don't seem to be protected by any authentication or ACL. Maybe we
> > could just have a simple security level check on these changes in the
> > rootdse code? Alternatively you could send the token in the irpc call
> > to the drepl server and have it do authentication or ACL checks.
> > The simplest is probably to say that rootdse modify is denied unless
> > you are at least SECURITY_DOMAIN_CONTROLLER level.
> > We also fixed up some build breakages caused by some recent changes in
> > the drepl server, and the conversion of the IRPC code to use binding
> > handles. We've put a fixed and rebased copy of your fsmo-fixed branch
> > in the nadya-fsmo-fixed in my git tree.
> Thanks for making this work i had troubles yesterday porting the IRPC
> stuff. I made a test for this implementation and i pushed it to
> There is the following problem with that test, it works with windows
> 1. schedule a partition pull with extended op
> 2. receive getncchanges with extended op, process it and return to sender
> 3. receive another getncchanges with extended op, process it and return to
> 4. callback is called for the 2nd but not for the first call
> 5. second call fails because there on step 3 we have already changed the
> The transfer goes well but the second extended op is totally unexpected and
> shows error.
> To reproduce this you can pull and run make test TESTS=fsmo
More information about the samba-technical