Re: [Samba] Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown
- Date: Fri, 8 Sep 2017 10:37:56 +0200
- From: "L.P.H. van Belle via samba" <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown
Sorry for the long wait, i had some things todo first here.
> -----Oorspronkelijk bericht-----
> Van: Sven Schwedas [mailto:sven.schwedas@xxxxxx]
> Verzonden: woensdag 6 september 2017 16:06
> Aan: L.P.H. van Belle; samba@xxxxxxxxxxxxxxx
> Onderwerp: Re: [Samba] Server GC/name.dom/dom is not
> registered with our KDC: Miscellaneous failure (see text):
> Server (GC/name/dom@DOM) unknown
> On 2017-09-06 09:28, L.P.H. van Belle wrote:
> >>> I suggest the following, move fsmo roles to villach-dc and
> >> check database replications.
> >> DB replication is already spewing errors, what am I to
> look out for?
> > Ok, get my check db script, run it from any dc. And post me
> the output.
> Output attached. Seems like all servers but graz-dc-sem have
> some stuff wrong, just wonderful.
Ok base on the log,
graz-dc-sem.ad.tao.at is the most complete/correct server.
> > https://github.com/thctlo/samba4/blob/master/samba-check-db-repl.sh
> Just FYI, something's wonky with the script. Bash trips up on
> CRLF line endings (everywhere) and 0xC2 control characters
> (ll. 260-261) sprinkled through the file. Had to clean that
> up before it actually ran without syntax errors.
Yes, sorry, i should have send this link.
> >>> Remove the most faulty one first, graz-dc-1b, from the
> >> domain. ( check
> >>> and cleanup DNS and AD! Very important )
> >> What to check for? What to clean up?
> > Ah, thats hard to tell, this depends a bit on the errors.
> > I search/look for the left overs, first with RSAT tools and
> samba-tool, then with ApacheStudio.
> > I look for hostnames/UUID/ things like that, but this is
> only done if all other options did not work.
> > But it depends on the errors/warnings i see/get.
> None of the differences look like they could cause the
> replication errors, looks more like they're just the results.
Faulty GUID/UUID's can and wil result in replication errors yes..
> >>>>> Then remove a failty server and re-add it as a new installed DC.
> >>>>> ( the good DS with FSMO)
> >>>>> First backup: /var/lib/samba/private/secrets.keytab
> >>>>> Remove the incorrect entries from keytab file with ktutil rkt
> >>>>> /var/lib/samba/private/secrets.keytab
> >>>>> list -e -t
> >>>> Might as well just nuke graz-dc-sem and add a complete
> new DC from
> >>>> scratch, no?
> >>> No, and yes, but i preffer no, not needed (yet).
> >>> Start with the keytab cleanup
> >>> Check the dns record if the uuid A PTR and hostnames
> >> resolve to the correct server.
> >>> If thats the case, then no, cleanup of keytab is, i think,
> >> sufficient.
> >> Just to confirm the order: Clean up the keytab, if that
> doesn't work,
> >> start removing servers?
> > Almost. Backup then ... Cleanup keytab of the server.
> I'll try that next, unless you find something shady in the report.
> >>> Yes, if its really a mess. ;-)
> >>> Then, first a an new DC, then remove, just make sure you
> >> always have 2
> >>> dc's up and running (correctly)
> >> Servers in Villach seem to run fine, thank $DEITY, so I'll
> leave them
> >> alone for now.
> > Ok, thats good, run the check-db script and post the
> complete output for me.
> >>>>> Now re-provision and you should have correct working
> DC's again.
> >>>>> ! Before re-provisioning, make sure all OLD records dns and
> >>>> AD are gone.
> >>>> I still have undeleteable replication records from the
> last time I
> >>>> had to nuke a DC, nobody replied to my emails on that issue.
> >>> Ok, now, im out of office in about 10 min, but mail that
> >> subject for me again> I'll have a look.
> >> First message on that topic:
> >> https://lists.samba.org/archive/samba/2017-March/207429.html
> > Ok, this one, track down both uuid's, checkout which which
> hostname belongs with these.
> Going by the output of `samba-tool drs showrepl` and sam.ldb,
> the GUIDs are as follows:
> graz-dc-sem 160f5a53-5c29-4a83-aeee-6cb1dbabeed7
> graz-dc-bis 7e4973ba-4093-4523-a70f-7caa4845e34d (not in sam.ldb)
> graz-dc-1b bcffbad8-1add-46b9-bf69-90e52c0f09ea
> villach-dc-sem eb5f9772-cd8f-4cde-9629-f1898c94aedd
> villach-dc-bis e1569c90-50f9-4bb5-bd85-79145e3ff6fd
> villach-sem/bis want to replicate to the dead and removed
> graz-dc-bis for some reason, but don't have its GUID in their
> sam.ldb either.
Ok, can you do a manualy check on graz-dc-sem and villach-dc-sem
Both command on each server.
samba-tool dbcheck --cross-nc
Error, post them.
> > Basicly https://wiki.samba.org/index.php/Demoting_a_Samba_AD_DC
> > In based on the Demoteing wiki example.
> > I do the same steps as shown there. Now the last three
> pictures on the site shows where to look.
> > At the site and Service, go through very folder, and check
> if it is as it should be.
> I already checked it back then, and double checked it now.
> ADUC, ADSS and DNS are all three clean and contain no
> reference to either the old server name or its GUID.
> > https://lists.samba.org/archive/samba/2017-March/207460.html
> > Between 2 and 3, there the problem starts
> >>> – I noticed a typo in the server's `netbios name`
> setting, corrected it, and restarted the DC.
> > 3. Yes, for the new hostname, the old hostname is as left
> over in the ADDC DB and/or DNS.
> > This name GRAZ-DC-BIS, and the name with the typo. The GUID
> for these is where to look info.
> Yeah, but where?
Now this is here ApacheStudio is very handy, but again, dont rush things here.
With ApacheStu.. Connect to the AD, and search for the faulty GUID/UUID's
Same for the hostname.
Ow did i tell you to make a backup first.. ;-) make it 2. ;-)
> > Step 6. ah the point of origin of you problems with of the
> current post?
> Hell if I know, but might be.
> > 7. dnsmasq? Ok, i just hope these are not running on the DC's.
> It's running on the gateways to cache the DCs' responses and
> handle some auxiliary stuff. ad.tao.at and all subdomains are
> transparently forwarded to the DCs, no difference in
> responses for _msdsc etc. between them and querying the DCs directly.
Ok, thats fine then.
> >> Last message, where I mentioned the replication bug:
> >> https://lists.samba.org/archive/samba/2017-April/207918.html
> >>> Own and if you dont use it, ApacheDirectoryStudio can help
> >> a lot with cleanup of these kind of things.
> >> Currently I'm using the ADSI MMC snap-in, any downsides
> compared to
> >> ADS?
> > I dont know, never used ADS :-/
> > Track done these : GUID's, the hostname's, ipnumbers A and
> PTR records
> > 7e4973ba-4093-4523-a70f-7caa4845e34d
> > d613fa11-064b-4bcc-ab01-20264f870f47
> > (how, see Verifying and Creating the objectGUID Record
> > d)
> Neither of the two return any results on any DC (or on the
> dnsmasq servers), but the GUIDs for the 4 currently existing
> DCs work fine. This matches the data from the RSAT tools.
Now, last, which is an option.
If one server hold a good and correct database, you can sync that one to the other servers.
But the database must be correct. ( and backuped 2 x )
samba-tool dbcheck --help gives also few extra options but i never used them so i cant tell much of these are usefull.
--reindex force database re-index
Rowland, can you give a educated answer on these also.
To unsubscribe from this list go to the following URL and read the