[Samba] Samba 4.4 AD DC and GET_ANC restriction from Samba 4.5 DC joining (was: Re: Error join samba 4.10.7 to samba 4.4.5)

Trenta sis trenta.sis at gmail.com
Tue Sep 17 10:52:29 UTC 2019


Hi,

About duplicate issues warning during join, What I can do to find and
solve this errors?
I like to investigate source of this issue and solve this errors before join

Thanks

Missatge de Trenta sis <trenta.sis at gmail.com> del dia dt., 10 de set.
2019 a les 11:14:
>
> Hi,
>
> About duplicate issues warning during join, What I can do to find and
> solve this errors?
>
> Thanks
>
> Missatge de Trenta sis <trenta.sis at gmail.com> del dia dl., 9 de set.
> 2019 a les 15:53:
> >
> > Hi Andrew,
> >
> > thanks for you information, but I have some question, I'm not a samba
> > expert... Sorry!
> >
> > Not that issue, but a very well known one.
> >
> > The trouble is, Samba 4.4 was happy to get a tree like this:
> >
> >
> >  X
> > | |
> > Y Z
> >
> > in an order like this:
> >
> > Step 1
> >
> > Y
> >
> > Step 2
> >
> > Y Z
> >
> > Step 3
> >  X
> > | |
> > Y Z
> >
> > As long as everything worked out in the end, it was fine.  But this had
> > issues, so we patched it to instead demand the objects in tree order
> > (GET_ANC), but of course the server needs to know what that means.
> >
> > Samba 4.5 was, from memory, the first release we did that, but the
> > server, even with 4.4, didn't really know what that flag meant.
> >
> > It wasn't until much later, Samba 4.6 or so, when we finally got the
> > flag right, which of course gives problems upgrading from Samba 4.4.
> > (We would sort the current 'page' of replication entries, but not the
> > whole partition).
> >
> > We have continued to improve this code since, but that is the core.
> > The next issue is a flag called GET_TGT but that hurts much less often,
> > as we have a client-side workaround detecting that the server didn't
> > understand us.
> >
> > The workaround for you is to carefully touch each object such that the
> > children are modified after the parents.  Or upgrade in-place that DC
> > and replicate from there.  Both suck, I know.
> >
> > --> Not really sure where is the issue, but moved domain users to
> > CN=Users and now join from 4.10.7 to 4.4.5 and seems to work!! Great!!
> >  Thanks!!!
> > During join some errors "duplciate value attribute CN=.." but I can
> > find what is duplicated, and some values that appears as duplciated
> > are not showed on RSAT tools,  any suggestion how to solve this
> > issues?
> >
> >
> > RFC2307, It seems that join has not added, I'll try to add manually
> > and also add some other config that are not added cert config
> >
> >
> > Thanks
> >
> > Missatge de Andrew Bartlett <abartlet at samba.org> del dia dl., 9 de
> > set. 2019 a les 11:14:
> > >
> > > On Mon, 2019-09-09 at 10:33 +0200, Trenta sis via samba wrote:
> > > > Hi,
> > > >
> > > > After reading wiki documentation about join I have tested to join a
> > > > second dc, but with problems.
> > > >
> > > > I need to add a second controller to our AD, and then upgrade existing
> > > > server (4.4.5)  and I have tried to join a new DC 4.10.7 to 4.4.5
> > > > server but I receive join errors, attached output  wit and without
> > > > debug:
> > > > I have executed samba-tool dbcheck --cross-ncs all seems OK
> > > >
> > > > I have made a test upgrading actual 4.4.5 to 4.10.7 and then join
> > > > 4.10.7 to update DC to 4.10.7 and then works, bu first I need to add a
> > > > second controller to ensure no downtime.
> > > >
> > > > some questions:
> > > > 1) Why I receive this error?
> > > > Replicating critical objects from the base DN of the domain
> > > > Partition[DC=DOMAIN-TEST,DC=com] objects[98/98] linked_values[762/0]
> > > > Missing parent while attempting to apply records: No parent with GUID
> > > > cdee5b31-365
> > > >
> > > > d-4c8f-9368-4115b6307a19 found for object remotely known as CN=Domain
> > > > Users,OU=Gru
> > > >
> > > > ps,DC=DOMAIN-TEST,DC=com
> > > > Failed to commit objects: WERR_DS_DRA_MISSING_PARENT
> > > >
> > > > --> not sure if can be related with this issue:
> > > > https://bugzilla.samba.org/show_bug.cgi?id=13274
> > >
> > > Not that issue, but a very well known one.
> > >
> > > The trouble is, Samba 4.4 was happy to get a tree like this:
> > >
> > >
> > >  X
> > > | |
> > > Y Z
> > >
> > > in an order like this:
> > >
> > > Step 1
> > >
> > > Y
> > >
> > > Step 2
> > >
> > > Y Z
> > >
> > > Step 3
> > >  X
> > > | |
> > > Y Z
> > >
> > > As long as everything worked out in the end, it was fine.  But this had
> > > issues, so we patched it to instead demand the objects in tree order
> > > (GET_ANC), but of course the server needs to know what that means.
> > >
> > > Samba 4.5 was, from memory, the first release we did that, but the
> > > server, even with 4.4, didn't really know what that flag meant.
> > >
> > > It wasn't until much later, Samba 4.6 or so, when we finally got the
> > > flag right, which of course gives problems upgrading from Samba 4.4.
> > > (We would sort the current 'page' of replication entries, but not the
> > > whole partition).
> > >
> > > We have continued to improve this code since, but that is the core.
> > > The next issue is a flag called GET_TGT but that hurts much less often,
> > > as we have a client-side workaround detecting that the server didn't
> > > understand us.
> > >
> > > The workaround for you is to carefully touch each object such that the
> > > children are modified after the parents.  Or upgrade in-place that DC
> > > and replicate from there.  Both suck, I know.
> > >
> > > > 2) About join in wiki appears
> > > > "
> > > > If the other DCs are Samba DCs and were provisioned with
> > > > --use-rfc2307, you Should add --option='idmap_ldb:use rfc2307 = yes'
> > > > to the join command
> > > > "
> > > >
> > > > But checking my command userv to migrate from samba nt doamin to our
> > > > actual ADDC domain this command was not used, but checking smb.conf
> > > > appears this:
> > > >  idmap_ldb:use rfc2307 = yes
> > > >
> > > > But I'm not sure if I have to use --option='idmap_ldb:use rfc2307 =
> > > > yes' on join command
> > >
> > > Probably.  But that isn't the big deal at this point.
> > >
> > > I hope this helps a little.  We need to extend our wiki to explain this
> > > more I'm sure.
> > >
> > > I've CC'ed samba-technical for those there who might want to learn the
> > > history a bit more.
> > >
> > > Andrew Bartlett
> > >
> > > --
> > > Andrew Bartlett                       http://samba.org/~abartlet/
> > > Authentication Developer, Samba Team  http://samba.org
> > > Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba
> > >
> > >



More information about the samba mailing list