Tried the join. Failed to find a writeable DC
Tried with --server and gave it the name of one of the servers. No luck
Tried a different server and....
itadmin at dc2020:/run/samba$ samba-tool domain join kcs.local DC
-U"KCS\domainadmin" --dns-backend=SAMBA_INTE
RNAL --server "luke.kcs.local"
Password for [KCS\domainadmin]:
INFO 2020-08-30 00:37:08,420 pid:175166
/usr/lib/python3/dist-packages/samba/join.py #1542: workgroup is KCS
INFO 2020-08-30 00:37:08,420 pid:175166
/usr/lib/python3/dist-packages/samba/join.py #1545: realm is kcs.local
Adding CN=DC2020,OU=Domain Controllers,DC=kcs,DC=local
Join failed - cleaning up
ERROR(ldb): uncaught exception - LDAP error 68 LDAP_ENTRY_ALREADY_EXISTS -
<00002071: ../ldb_tdb/ldb_index .c:1339: Failed
to re-index objectSid in CN=DC2020,OU=Domain Controllers,DC=kcs,DC=local -
../ldb_tdb/ldb_i ndex.c:1259: unique index
violation on objectSid in CN=DC2020,OU=Domain Controllers,DC=kcs,DC=local>
<>
File "/usr/lib/python3/dist-packages/samba/netcmd/__init__.py", line
186,
in _run
return self.run(*args, **kwargs)
File "/usr/lib/python3/dist-packages/samba/netcmd/domain.py", line
701,
in run
join_DC(logger=logger, server=server, creds=creds, lp=lp, domain=domain,
File "/usr/lib/python3/dist-packages/samba/join.py", line 1558, in
join_DC
ctx.do_join()
File "/usr/lib/python3/dist-packages/samba/join.py", line 1446, in
do_join
ctx.join_add_objects()
File "/usr/lib/python3/dist-packages/samba/join.py", line 654, in
join_add_objects
ctx.samdb.add(rec, controls=controls)
Does the world just hate me?
On Sat, Aug 29, 2020 at 5:35 PM Andrew Bartlett <abartlet at samba.org>
wrote:
> A join might be all your need, but given the source version you can't
> do an offline backup, so I would then see if you can use our online
> backup tool, then restore from there.
>
> Andrew Bartlett
>
> On Sat, 2020-08-29 at 17:02 -0700, Peter Pollock wrote:
> > Of course, it seems we are running Samba 4.7.6-Ubuntu.
> >
> > Great.
> >
> > The biggest regret of my last few years is that we are also running
> Zentyal, which I am desperate to get rid of.
> >
> > I'm trying to build a new server with the latest Samba and join
that to
> the domain to see if I can get a good copy of the database, then wipe the
> other servers and rebuild them from scratch
> >
> > On Sat, Aug 29, 2020 at 3:04 PM Andrew Bartlett <abartlet at
samba.org>
> wrote:
> > > Given the situation in the world today, I would agree a desert
island
> > > sounds ideal.
> > >
> > > However I think there is hope for your network, so you can run
away in
> > > peace.
> > >
> > > First, you have not said which Samba versions you are using, so
the
> > > advise below is a bit generic.
> > >
> > > If my network was behaving like this I would use Samba's
backup tools
> > > to make a backup, and start again with the restored domain, again
using
> > > our restore tools. The restore will manage the FSMO roles and
clean up
> > > pile of stuff as part of removing the other domain controllers.
> > >
> > > samba-tool domain backup
> > > samba-tool domain restore
> > >
> > > There are offline and online backup options, I would try both and
see
> > > which works given the situations you are in.
> > >
> > > Also, the schema should be fixable. We have tools to load a new
schema
> > > into Samba - you might be missing the schema file
> > >
> > > source4/setup/adprep/samba-4.7-missing-for-schema45.ldif
> > >
> > > This is in the tarball (but not installed, a bug) and consists of
the
> > > difference between the schema we had and the schema we claimed to
have
> > > as schema version 45.
> > >
> > > In terms of the permissions, you may have lost idmap.ldb, so the
> > > mapping between unix uids and Samba SIDs would be scrambled. Do
note
> > > that this is not replicated either.
> > >
> > > I hope these suggestions help.
> > >
> > > Andrew Bartlett
> > >
> > > On Sat, 2020-08-29 at 14:44 -0700, Peter Pollock via samba wrote:
> > > > Thank you for your assistance.
> > > >
> > > > Turns out everything is really really screwed up and I
can't even add
> > > > a DC
> > > > right now. I thought I had added a third and it seemed to be
> > > > replicating
> > > > but now the other two won't recognize it as a DC.
> > > >
> > > > I'm so deep in this hole right now I'm considering
nuking the whole
> > > > thing,
> > > > quitting my job and moving to a desert island. It seriously
couldn't
> > > > make
> > > > it any worse.
> > > >
> > > > On Sun, Aug 16, 2020 at 11:39 PM Rowland penny via samba
<
> > > > samba at lists.samba.org> wrote:
> > > >
> > > > > On 17/08/2020 04:21, Peter Pollock via samba wrote:
> > > > > > So I screwed up my AD.
> > > > > >
> > > > > > At some point a Windows 2019 server was attempted
to be added and
> > > > > > it
> > > > >
> > > > > messed
> > > > > > the schema up.
> > > > > >
> > > > > > That server was removed and ceremonially burned in
the fire pit
> > > > > > but I
> > > > > > couldn't fix the issues that had arisen, so I
restored both of
> > > > > > the
> > > > >
> > > > > original
> > > > > > Samba DC's from backups
> > > > >
> > > > > That is probably where your main problems start, you
should never
> > > > > restore an individual DC, you only restore a domain.
You restored
> > > > > two
> > > > > DC's from backups, were the backups taken at
exactly the same time
> > > > > ?
> > > > >
> > > > > What you should have done was, restore one DC, seize
all FSMO roles
> > > > > to
> > > > > this DC, forcibly demote any other DC's and then
clean up the other
> > > > > DC's
> > > > > and rejoined them to the domain as new DC's
> > > > >
> > > > > > and everything LOOKS OK on the surface, but
they're
> > > > > > not replicating and for some reason some of the
permissions on
> > > > > > the drive
> > > > > > containing the home folders got changed even
though the restore
> > > > > > had
> > > > >
> > > > > nothing
> > > > > > to do with that drive... and there are other weird
issues, like
> > > > > > the
> > > > >
> > > > > windows
> > > > > > computers trying to log on randomly say there is
no trust
> > > > > > relationship
> > > > > > between them and the domain.
> > > > > >
> > > > > > It's all weird and I can't work out how to
fix any of it.
> > > > > >
> > > > > > I built a new DC (DC3) and that initially got a
copy of
> > > > > > everything from
> > > > >
> > > > > one
> > > > > > of the original DC's but after that they
won't replicate to it.
> > > > > > It can
> > > > > > replicate outbound with both of the other DC's
but not inbound
> > > > > > and DC1
> > > > >
> > > > > and
> > > > > > DC2 won't replicate with each other at all.
> > > > > >
> > > > > > We are a small school and have virtually zero
budget (latest DC
> > > > > > is built
> > > > >
> > > > > on
> > > > > > an old desktop, so it can't stay around
forever) but I've managed
> > > > > > to get
> > > > > > funding for a new server, which might help.
> > > > > >
> > > > > > One of my big problems is that we only have (or
had) 2 servers. I
> > > > >
> > > > > couldn't
> > > > > > risk not having a backup DC so I built them both
as samba DC's -
> > > > > > but one
> > > > >
> > > > > is
> > > > > > also the fileserver. (I know, fileserves
shouldn't be DC's but I
> > > > > > didn't
> > > > > > have much choice).
> > > > > >
> > > > > > I don't know how to fix the problems and have
decided I probably
> > > > > > need to
> > > > > > rebuild both of the problem servers from scratch,
but my
> > > > > > understanding is
> > > > > > that if I do that, I have to demote them then
rebuild them with
> > > > > > different
> > > > > > names so the AD doesn't get confused. Is that
right?
> > > > >
> > > > > You can re-use the names, but you must ensure the DC is
fully
> > > > > demoted
> > > > > and cleaned up before the join.
> > > > > >
> > > > > > My issue there is the shares on the fileserver.
All the windows
> > > > > > drive
> > > > > > mappings on the client machines are to
\\dc02\sharename - and
> > > > > > they won't
> > > > > > work any more if I rebuild with a different server
name. Is there
> > > > > > a way
> > > > >
> > > > > to
> > > > > > migrate them across?
> > > > > >
> > > > > > My fear is also that there is something screwy
with the schema
> > > > > > even now
> > > > >
> > > > > and
> > > > > > just rebuilding won't fix that so I'm
wondering if I should start
> > > > > > again
> > > > > > from scratch with a completely new domain, somehow
import all the
> > > > > > user
> > > > > > details and go around manually rejoining all the
workstations.
> > > > >
> > > > > If you have a backup from before the Windows 2019 DC
was joined,
> > > > > you
> > > > > should be able to fix this, but you will lose any
changes made to
> > > > > AD
> > > > > after the backup was made.
> > > > > >
> > > > > > I'm looking for advice here. I know I've
messed up bad but I have
> > > > > > to try
> > > > >
> > > > > to
> > > > > > fix it, although that's hard because now
school is back in
> > > > > > session I
> > > > >
> > > > > can't
> > > > > > do anything during the day, partly because I'm
teaching and
> > > > > > partly
> > > > >
> > > > > because
> > > > > > the teachers rely on the network for their
teaching. I'm going to
> > > > > > take
> > > > >
> > > > > the
> > > > > > school offline in a couple of weeks for an entire
weekend to fix
> > > > > > this
> > > > > > nonsense... I just don't know what the best
way to go about
> > > > > > fixing it is?
> > > > >
> > > > > It sounds like you now have three machines to use,
perhaps use one
> > > > > as a
> > > > > Unix domain member running as a fileserver and the
other two as
> > > > > DC's.
> > > > >
> > > > > Rowland
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe from this list go to the following URL
and read the
> > > > > instructions:
https://lists.samba.org/mailman/options/samba
> > > > >
> --
> Andrew Bartlett http://samba.org/~abartlet/
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Catalyst IT
> http://catalyst.net.nz/services/samba
>
>
>
You have a duplicate RID pool, so the RIDs that it thinks it can allocate are already allocated. dbcheck on Samba 4.5 and later (so should work for your 4.7) can fix that. Run that on the source server locally. Andrew Bartlett On Sat, 2020-08-29 at 17:42 -0700, Peter Pollock wrote:> Tried the join. Failed to find a writeable DC > Tried with --server and gave it the name of one of the servers. No luck > > Tried a different server and.... > > itadmin at dc2020:/run/samba$ samba-tool domain join kcs.local DC -U"KCS\domainadmin" --dns-backend=SAMBA_INTE RNAL --server "luke.kcs.local" > Password for [KCS\domainadmin]: > INFO 2020-08-30 00:37:08,420 pid:175166 /usr/lib/python3/dist-packages/samba/join.py #1542: workgroup is KCS > INFO 2020-08-30 00:37:08,420 pid:175166 /usr/lib/python3/dist-packages/samba/join.py #1545: realm is kcs.local > Adding CN=DC2020,OU=Domain Controllers,DC=kcs,DC=local > Join failed - cleaning up > ERROR(ldb): uncaught exception - LDAP error 68 LDAP_ENTRY_ALREADY_EXISTS - <00002071: ../ldb_tdb/ldb_index .c:1339: Failed to re-index objectSid in CN=DC2020,OU=Domain Controllers,DC=kcs,DC=local - ../ldb_tdb/ldb_i ndex.c:1259: unique index violation on objectSid in CN=DC2020,OU=Domain Controllers,DC=kcs,DC=local> <> > File "/usr/lib/python3/dist-packages/samba/netcmd/__init__.py", line 186, in _run > return self.run(*args, **kwargs) > File "/usr/lib/python3/dist-packages/samba/netcmd/domain.py", line 701, in run > join_DC(logger=logger, server=server, creds=creds, lp=lp, domain=domain, > File "/usr/lib/python3/dist-packages/samba/join.py", line 1558, in join_DC > ctx.do_join() > File "/usr/lib/python3/dist-packages/samba/join.py", line 1446, in do_join > ctx.join_add_objects() > File "/usr/lib/python3/dist-packages/samba/join.py", line 654, in join_add_objects > ctx.samdb.add(rec, controls=controls) > > Does the world just hate me? > > On Sat, Aug 29, 2020 at 5:35 PM Andrew Bartlett <abartlet at samba.org> wrote: > > A join might be all your need, but given the source version you can't > > do an offline backup, so I would then see if you can use our online > > backup tool, then restore from there. > > > > Andrew Bartlett > > > > On Sat, 2020-08-29 at 17:02 -0700, Peter Pollock wrote: > > > Of course, it seems we are running Samba 4.7.6-Ubuntu. > > > > > > Great. > > > > > > The biggest regret of my last few years is that we are also running Zentyal, which I am desperate to get rid of. > > > > > > I'm trying to build a new server with the latest Samba and join that to the domain to see if I can get a good copy of the database, then wipe the other servers and rebuild them from scratch > > > > > > On Sat, Aug 29, 2020 at 3:04 PM Andrew Bartlett <abartlet at samba.org> wrote: > > > > Given the situation in the world today, I would agree a desert island > > > > sounds ideal. > > > > > > > > However I think there is hope for your network, so you can run away in > > > > peace. > > > > > > > > First, you have not said which Samba versions you are using, so the > > > > advise below is a bit generic. > > > > > > > > If my network was behaving like this I would use Samba's backup tools > > > > to make a backup, and start again with the restored domain, again using > > > > our restore tools. The restore will manage the FSMO roles and clean up > > > > pile of stuff as part of removing the other domain controllers. > > > > > > > > samba-tool domain backup > > > > samba-tool domain restore > > > > > > > > There are offline and online backup options, I would try both and see > > > > which works given the situations you are in. > > > > > > > > Also, the schema should be fixable. We have tools to load a new schema > > > > into Samba - you might be missing the schema file > > > > > > > > source4/setup/adprep/samba-4.7-missing-for-schema45.ldif > > > > > > > > This is in the tarball (but not installed, a bug) and consists of the > > > > difference between the schema we had and the schema we claimed to have > > > > as schema version 45. > > > > > > > > In terms of the permissions, you may have lost idmap.ldb, so the > > > > mapping between unix uids and Samba SIDs would be scrambled. Do note > > > > that this is not replicated either. > > > > > > > > I hope these suggestions help. > > > > > > > > Andrew Bartlett > > > > > > > > On Sat, 2020-08-29 at 14:44 -0700, Peter Pollock via samba wrote: > > > > > Thank you for your assistance. > > > > > > > > > > Turns out everything is really really screwed up and I can't even add > > > > > a DC > > > > > right now. I thought I had added a third and it seemed to be > > > > > replicating > > > > > but now the other two won't recognize it as a DC. > > > > > > > > > > I'm so deep in this hole right now I'm considering nuking the whole > > > > > thing, > > > > > quitting my job and moving to a desert island. It seriously couldn't > > > > > make > > > > > it any worse. > > > > > > > > > > On Sun, Aug 16, 2020 at 11:39 PM Rowland penny via samba < > > > > > samba at lists.samba.org> wrote: > > > > > > > > > > > On 17/08/2020 04:21, Peter Pollock via samba wrote: > > > > > > > So I screwed up my AD. > > > > > > > > > > > > > > At some point a Windows 2019 server was attempted to be added and > > > > > > > it > > > > > > > > > > > > messed > > > > > > > the schema up. > > > > > > > > > > > > > > That server was removed and ceremonially burned in the fire pit > > > > > > > but I > > > > > > > couldn't fix the issues that had arisen, so I restored both of > > > > > > > the > > > > > > > > > > > > original > > > > > > > Samba DC's from backups > > > > > > > > > > > > That is probably where your main problems start, you should never > > > > > > restore an individual DC, you only restore a domain. You restored > > > > > > two > > > > > > DC's from backups, were the backups taken at exactly the same time > > > > > > ? > > > > > > > > > > > > What you should have done was, restore one DC, seize all FSMO roles > > > > > > to > > > > > > this DC, forcibly demote any other DC's and then clean up the other > > > > > > DC's > > > > > > and rejoined them to the domain as new DC's > > > > > > > > > > > > > and everything LOOKS OK on the surface, but they're > > > > > > > not replicating and for some reason some of the permissions on > > > > > > > the drive > > > > > > > containing the home folders got changed even though the restore > > > > > > > had > > > > > > > > > > > > nothing > > > > > > > to do with that drive... and there are other weird issues, like > > > > > > > the > > > > > > > > > > > > windows > > > > > > > computers trying to log on randomly say there is no trust > > > > > > > relationship > > > > > > > between them and the domain. > > > > > > > > > > > > > > It's all weird and I can't work out how to fix any of it. > > > > > > > > > > > > > > I built a new DC (DC3) and that initially got a copy of > > > > > > > everything from > > > > > > > > > > > > one > > > > > > > of the original DC's but after that they won't replicate to it. > > > > > > > It can > > > > > > > replicate outbound with both of the other DC's but not inbound > > > > > > > and DC1 > > > > > > > > > > > > and > > > > > > > DC2 won't replicate with each other at all. > > > > > > > > > > > > > > We are a small school and have virtually zero budget (latest DC > > > > > > > is built > > > > > > > > > > > > on > > > > > > > an old desktop, so it can't stay around forever) but I've managed > > > > > > > to get > > > > > > > funding for a new server, which might help. > > > > > > > > > > > > > > One of my big problems is that we only have (or had) 2 servers. I > > > > > > > > > > > > couldn't > > > > > > > risk not having a backup DC so I built them both as samba DC's - > > > > > > > but one > > > > > > > > > > > > is > > > > > > > also the fileserver. (I know, fileserves shouldn't be DC's but I > > > > > > > didn't > > > > > > > have much choice). > > > > > > > > > > > > > > I don't know how to fix the problems and have decided I probably > > > > > > > need to > > > > > > > rebuild both of the problem servers from scratch, but my > > > > > > > understanding is > > > > > > > that if I do that, I have to demote them then rebuild them with > > > > > > > different > > > > > > > names so the AD doesn't get confused. Is that right? > > > > > > > > > > > > You can re-use the names, but you must ensure the DC is fully > > > > > > demoted > > > > > > and cleaned up before the join. > > > > > > > > > > > > > > My issue there is the shares on the fileserver. All the windows > > > > > > > drive > > > > > > > mappings on the client machines are to \\dc02\sharename - and > > > > > > > they won't > > > > > > > work any more if I rebuild with a different server name. Is there > > > > > > > a way > > > > > > > > > > > > to > > > > > > > migrate them across? > > > > > > > > > > > > > > My fear is also that there is something screwy with the schema > > > > > > > even now > > > > > > > > > > > > and > > > > > > > just rebuilding won't fix that so I'm wondering if I should start > > > > > > > again > > > > > > > from scratch with a completely new domain, somehow import all the > > > > > > > user > > > > > > > details and go around manually rejoining all the workstations. > > > > > > > > > > > > If you have a backup from before the Windows 2019 DC was joined, > > > > > > you > > > > > > should be able to fix this, but you will lose any changes made to > > > > > > AD > > > > > > after the backup was made. > > > > > > > > > > > > > > I'm looking for advice here. I know I've messed up bad but I have > > > > > > > to try > > > > > > > > > > > > to > > > > > > > fix it, although that's hard because now school is back in > > > > > > > session I > > > > > > > > > > > > can't > > > > > > > do anything during the day, partly because I'm teaching and > > > > > > > partly > > > > > > > > > > > > because > > > > > > > the teachers rely on the network for their teaching. I'm going to > > > > > > > take > > > > > > > > > > > > the > > > > > > > school offline in a couple of weeks for an entire weekend to fix > > > > > > > this > > > > > > > nonsense... I just don't know what the best way to go about > > > > > > > fixing it is? > > > > > > > > > > > > It sounds like you now have three machines to use, perhaps use one > > > > > > as a > > > > > > Unix domain member running as a fileserver and the other two as > > > > > > DC's. > > > > > > > > > > > > Rowland > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > To unsubscribe from this list go to the following URL and read the > > > > > > instructions: https://lists.samba.org/mailman/options/samba > > > > > >-- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
Yeah, I already tried that, to no avail. I finally had some modicum of success. Switched everything off except one server, then restored that from June and was able to then build a new server and join it to the domain. And everything was peachy. Except the original server has some stupid zentyal issues which no one on the zentyal boards can help me fix and when I then demoted the original (zentyal) server and rebuilt it then tried to rejoin, it couldn't see the other server I'd built. 4 hours later, bind configured, forward and reverse zones created, and the windows clients can't see it. So... back to the restore I went and now I'm going to sleep on it and see if I can work out some way tomorrow to get things working so I can wipe these stupid zentyal boxes and build them myself. Thank you guys for your help... but a small nuke detonated between the servers followed by me disappearing off to that desert island seems more and more likely. On Sat, Aug 29, 2020, 10:18 PM Andrew Bartlett <abartlet at samba.org> wrote:> You have a duplicate RID pool, so the RIDs that it thinks it can > allocate are already allocated. dbcheck on Samba 4.5 and later (so > should work for your 4.7) can fix that. > > Run that on the source server locally. > > Andrew Bartlett > > On Sat, 2020-08-29 at 17:42 -0700, Peter Pollock wrote: > > Tried the join. Failed to find a writeable DC > > Tried with --server and gave it the name of one of the servers. No luck > > > > Tried a different server and.... > > > > itadmin at dc2020:/run/samba$ samba-tool domain join kcs.local DC > -U"KCS\domainadmin" --dns-backend=SAMBA_INTE > RNAL --server "luke.kcs.local" > > Password for [KCS\domainadmin]: > > INFO 2020-08-30 00:37:08,420 pid:175166 > /usr/lib/python3/dist-packages/samba/join.py #1542: workgroup is KCS > > INFO 2020-08-30 00:37:08,420 pid:175166 > /usr/lib/python3/dist-packages/samba/join.py #1545: realm is kcs.local > > Adding CN=DC2020,OU=Domain Controllers,DC=kcs,DC=local > > Join failed - cleaning up > > ERROR(ldb): uncaught exception - LDAP error 68 LDAP_ENTRY_ALREADY_EXISTS > - <00002071: ../ldb_tdb/ldb_index .c:1339: > Failed to re-index objectSid in CN=DC2020,OU=Domain > Controllers,DC=kcs,DC=local - ../ldb_tdb/ldb_i > ndex.c:1259: unique index violation on objectSid in CN=DC2020,OU=Domain > Controllers,DC=kcs,DC=local> <> > > File "/usr/lib/python3/dist-packages/samba/netcmd/__init__.py", line > 186, in _run > > return self.run(*args, **kwargs) > > File "/usr/lib/python3/dist-packages/samba/netcmd/domain.py", line > 701, in run > > join_DC(logger=logger, server=server, creds=creds, lp=lp, > domain=domain, > > File "/usr/lib/python3/dist-packages/samba/join.py", line 1558, in > join_DC > > ctx.do_join() > > File "/usr/lib/python3/dist-packages/samba/join.py", line 1446, in > do_join > > ctx.join_add_objects() > > File "/usr/lib/python3/dist-packages/samba/join.py", line 654, in > join_add_objects > > ctx.samdb.add(rec, controls=controls) > > > > Does the world just hate me? > > > > On Sat, Aug 29, 2020 at 5:35 PM Andrew Bartlett <abartlet at samba.org> > wrote: > > > A join might be all your need, but given the source version you can't > > > do an offline backup, so I would then see if you can use our online > > > backup tool, then restore from there. > > > > > > Andrew Bartlett > > > > > > On Sat, 2020-08-29 at 17:02 -0700, Peter Pollock wrote: > > > > Of course, it seems we are running Samba 4.7.6-Ubuntu. > > > > > > > > Great. > > > > > > > > The biggest regret of my last few years is that we are also running > Zentyal, which I am desperate to get rid of. > > > > > > > > I'm trying to build a new server with the latest Samba and join that > to the domain to see if I can get a good copy of the database, then wipe > the other servers and rebuild them from scratch > > > > > > > > On Sat, Aug 29, 2020 at 3:04 PM Andrew Bartlett <abartlet at samba.org> > wrote: > > > > > Given the situation in the world today, I would agree a desert > island > > > > > sounds ideal. > > > > > > > > > > However I think there is hope for your network, so you can run > away in > > > > > peace. > > > > > > > > > > First, you have not said which Samba versions you are using, so the > > > > > advise below is a bit generic. > > > > > > > > > > If my network was behaving like this I would use Samba's backup > tools > > > > > to make a backup, and start again with the restored domain, again > using > > > > > our restore tools. The restore will manage the FSMO roles and > clean up > > > > > pile of stuff as part of removing the other domain controllers. > > > > > > > > > > samba-tool domain backup > > > > > samba-tool domain restore > > > > > > > > > > There are offline and online backup options, I would try both and > see > > > > > which works given the situations you are in. > > > > > > > > > > Also, the schema should be fixable. We have tools to load a new > schema > > > > > into Samba - you might be missing the schema file > > > > > > > > > > source4/setup/adprep/samba-4.7-missing-for-schema45.ldif > > > > > > > > > > This is in the tarball (but not installed, a bug) and consists of > the > > > > > difference between the schema we had and the schema we claimed to > have > > > > > as schema version 45. > > > > > > > > > > In terms of the permissions, you may have lost idmap.ldb, so the > > > > > mapping between unix uids and Samba SIDs would be scrambled. Do > note > > > > > that this is not replicated either. > > > > > > > > > > I hope these suggestions help. > > > > > > > > > > Andrew Bartlett > > > > > > > > > > On Sat, 2020-08-29 at 14:44 -0700, Peter Pollock via samba wrote: > > > > > > Thank you for your assistance. > > > > > > > > > > > > Turns out everything is really really screwed up and I can't > even add > > > > > > a DC > > > > > > right now. I thought I had added a third and it seemed to be > > > > > > replicating > > > > > > but now the other two won't recognize it as a DC. > > > > > > > > > > > > I'm so deep in this hole right now I'm considering nuking the > whole > > > > > > thing, > > > > > > quitting my job and moving to a desert island. It seriously > couldn't > > > > > > make > > > > > > it any worse. > > > > > > > > > > > > On Sun, Aug 16, 2020 at 11:39 PM Rowland penny via samba < > > > > > > samba at lists.samba.org> wrote: > > > > > > > > > > > > > On 17/08/2020 04:21, Peter Pollock via samba wrote: > > > > > > > > So I screwed up my AD. > > > > > > > > > > > > > > > > At some point a Windows 2019 server was attempted to be > added and > > > > > > > > it > > > > > > > > > > > > > > messed > > > > > > > > the schema up. > > > > > > > > > > > > > > > > That server was removed and ceremonially burned in the fire > pit > > > > > > > > but I > > > > > > > > couldn't fix the issues that had arisen, so I restored both > of > > > > > > > > the > > > > > > > > > > > > > > original > > > > > > > > Samba DC's from backups > > > > > > > > > > > > > > That is probably where your main problems start, you should > never > > > > > > > restore an individual DC, you only restore a domain. You > restored > > > > > > > two > > > > > > > DC's from backups, were the backups taken at exactly the same > time > > > > > > > ? > > > > > > > > > > > > > > What you should have done was, restore one DC, seize all FSMO > roles > > > > > > > to > > > > > > > this DC, forcibly demote any other DC's and then clean up the > other > > > > > > > DC's > > > > > > > and rejoined them to the domain as new DC's > > > > > > > > > > > > > > > and everything LOOKS OK on the surface, but they're > > > > > > > > not replicating and for some reason some of the permissions > on > > > > > > > > the drive > > > > > > > > containing the home folders got changed even though the > restore > > > > > > > > had > > > > > > > > > > > > > > nothing > > > > > > > > to do with that drive... and there are other weird issues, > like > > > > > > > > the > > > > > > > > > > > > > > windows > > > > > > > > computers trying to log on randomly say there is no trust > > > > > > > > relationship > > > > > > > > between them and the domain. > > > > > > > > > > > > > > > > It's all weird and I can't work out how to fix any of it. > > > > > > > > > > > > > > > > I built a new DC (DC3) and that initially got a copy of > > > > > > > > everything from > > > > > > > > > > > > > > one > > > > > > > > of the original DC's but after that they won't replicate to > it. > > > > > > > > It can > > > > > > > > replicate outbound with both of the other DC's but not > inbound > > > > > > > > and DC1 > > > > > > > > > > > > > > and > > > > > > > > DC2 won't replicate with each other at all. > > > > > > > > > > > > > > > > We are a small school and have virtually zero budget (latest > DC > > > > > > > > is built > > > > > > > > > > > > > > on > > > > > > > > an old desktop, so it can't stay around forever) but I've > managed > > > > > > > > to get > > > > > > > > funding for a new server, which might help. > > > > > > > > > > > > > > > > One of my big problems is that we only have (or had) 2 > servers. I > > > > > > > > > > > > > > couldn't > > > > > > > > risk not having a backup DC so I built them both as samba > DC's - > > > > > > > > but one > > > > > > > > > > > > > > is > > > > > > > > also the fileserver. (I know, fileserves shouldn't be DC's > but I > > > > > > > > didn't > > > > > > > > have much choice). > > > > > > > > > > > > > > > > I don't know how to fix the problems and have decided I > probably > > > > > > > > need to > > > > > > > > rebuild both of the problem servers from scratch, but my > > > > > > > > understanding is > > > > > > > > that if I do that, I have to demote them then rebuild them > with > > > > > > > > different > > > > > > > > names so the AD doesn't get confused. Is that right? > > > > > > > > > > > > > > You can re-use the names, but you must ensure the DC is fully > > > > > > > demoted > > > > > > > and cleaned up before the join. > > > > > > > > > > > > > > > > My issue there is the shares on the fileserver. All the > windows > > > > > > > > drive > > > > > > > > mappings on the client machines are to \\dc02\sharename - > and > > > > > > > > they won't > > > > > > > > work any more if I rebuild with a different server name. Is > there > > > > > > > > a way > > > > > > > > > > > > > > to > > > > > > > > migrate them across? > > > > > > > > > > > > > > > > My fear is also that there is something screwy with the > schema > > > > > > > > even now > > > > > > > > > > > > > > and > > > > > > > > just rebuilding won't fix that so I'm wondering if I should > start > > > > > > > > again > > > > > > > > from scratch with a completely new domain, somehow import > all the > > > > > > > > user > > > > > > > > details and go around manually rejoining all the > workstations. > > > > > > > > > > > > > > If you have a backup from before the Windows 2019 DC was > joined, > > > > > > > you > > > > > > > should be able to fix this, but you will lose any changes made > to > > > > > > > AD > > > > > > > after the backup was made. > > > > > > > > > > > > > > > > I'm looking for advice here. I know I've messed up bad but I > have > > > > > > > > to try > > > > > > > > > > > > > > to > > > > > > > > fix it, although that's hard because now school is back in > > > > > > > > session I > > > > > > > > > > > > > > can't > > > > > > > > do anything during the day, partly because I'm teaching and > > > > > > > > partly > > > > > > > > > > > > > > because > > > > > > > > the teachers rely on the network for their teaching. I'm > going to > > > > > > > > take > > > > > > > > > > > > > > the > > > > > > > > school offline in a couple of weeks for an entire weekend to > fix > > > > > > > > this > > > > > > > > nonsense... I just don't know what the best way to go about > > > > > > > > fixing it is? > > > > > > > > > > > > > > It sounds like you now have three machines to use, perhaps use > one > > > > > > > as a > > > > > > > Unix domain member running as a fileserver and the other two as > > > > > > > DC's. > > > > > > > > > > > > > > Rowland > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > To unsubscribe from this list go to the following URL and read > the > > > > > > > instructions: https://lists.samba.org/mailman/options/samba > > > > > > > > -- > Andrew Bartlett http://samba.org/~abartlet/ > Authentication Developer, Samba Team http://samba.org > Samba Developer, Catalyst IT > http://catalyst.net.nz/services/samba > > >