[Samba] Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom at DOM) unknown

Fri Sep 8 08:37:56 UTC 2017

Hai Sven, 

Sorry for the long wait, i had some things todo first here.

> -----Oorspronkelijk bericht-----
> Van: Sven Schwedas [mailto:sven.schwedas at tao.at] 
> Verzonden: woensdag 6 september 2017 16:06
> Aan: L.P.H. van Belle; samba at lists.samba.org
> Onderwerp: Re: [Samba] Server GC/name.dom/dom is not 
> registered with our KDC: Miscellaneous failure (see text): 
> Server (GC/name/dom at 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. 
https://raw.githubusercontent.com/thctlo/samba4/master/samba-check-db-repl.sh 

> 
> >>> 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 
And 
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  
> > 
> https://wiki.samba.org/index.php/Verifying_and_Creating_a_DC_DNS_Recor
> > 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 
  --reset-well-known-acls
  --cross-ncs  

Rowland, can you give a educated answer on these also. 

Greetz, 

Louis