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

L.P.H. van Belle belle at bazuin.nl
Fri Sep 8 14:34:36 UTC 2017


 

> -----Oorspronkelijk bericht-----
> Van: Sven Schwedas [mailto:sven.schwedas at tao.at] 
> Verzonden: vrijdag 8 september 2017 14:40
> 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-08 10:37, L.P.H. van Belle wrote:
> > Hai Sven,
> > 
> > Sorry for the long wait, i had some things todo first here.
> 
> 's fine. It's not like I don't have other stuff to worry about either.
Pfew, im thinging your just waiting for me ;-) 

> 
> >> -----Oorspronkelijk bericht-----
> >>>>> 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. 
> 
> And also the one with the keytab problems. :(
Ok, yes, but wait, read on... 

> 
> >>>>>>> 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
> >>>>>>
> >>>>> 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.
> 
> While going through the records with Directory Studio I 
> noticed that the duplicate keytab entries are mirrored by 
> servicePrincipalName entries in CN=GRAZ-DC-SEM,OU=Domain 
> Controllers,DC=ad,DC=tao,DC=at
> 
> Which should I clean up, and in what order? LDAP first, then keytab?
> Just LDAP?
Now, only remove the incorrect ones from : servicePrincipalName 
You can do this also very easy from withing RSAT "User and Domain manager"
Enable advanced view. 
Right klik on the computer object, properties goto tab: Attribute Editor

servicePrincipalName
edit and remove the failty ones 
And ok, exit. 

! Dont add there. (not now, first fix everything. ) 

> 
> >>>> 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. 
> 
> About that? villach-dc-sem is down because its VM host went 
> poof yesterday. :/ Gonna get it repaired at some point next week.
> 
Option. 
Well this is you change... Get it, setup a clean server. 
Join the domain, Seize the FSMO roles after AD syncs are done. 
Push this AD DB to the other servers. s

> On graz-dc-sem, samba-tool dbcheck shows zero errors. 
> --cross-nc gives:
> 
> > Error: governsID 
> > CN=ucsUser,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on 
> > 1.3.6.1.4.1.19414.3.2.2 already exists as an attributeId or 
> governsId
> > Error: governsID 
> > CN=taoSharedFolder,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on 
> > 1.3.6.1.4.1.19414.3.2.4 already exists as an attributeId or 
> governsId
> > Error: governsID 
> > CN=taoMailingList,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on 
> > 1.3.6.1.4.1.19414.3.2.3 already exists as an attributeId or 
> governsId
> 
> Those are presumably from me fucking around with custom LDAP 
> attributes years ago and don't seem to be related. I hope.
I hope so to, i dont know that yet, but are these sill used somewere? 
If not, run safely : samba-tool dbcheck --cross-nc --fix 
If they are used, well, run it also, but prepair for extra (possible) problems.

> 
> >>>>>  ? 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. ;-)
> 
> No results for either the old name, nor the new name, nor the 
> GUID, on any server.
> 
> How is `drs showrepl` giving me the UUID for something that's 
> nowhere in LDAP?

Huh, yeah thats very strange, then, its still there, 
You should find it somewhere, i think your search is off, you did set the BASE DN also? 

And i forgot this one : samba-tool domain tombstones expunge
That cleanup the AD also from deleted items. 


> 
> > 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 )
> 
> So
> 
> 1. Back up graz-dc-sem
> 2. purge the duplicate keytab/SPN magic voodoo somehow (see 
> above) 
> 3. Force sync?

Now since im having a hardtime myself here with a keytab problem.  
I think a bug due GnPG2 still investigating it.  ( kerberos nfs and AES key errors ) 
I suggest, we ask a dev the best way to cleanup the keytab file. 
I have several ways, but i want to know what the devs say also about this. 
And fideling around with keytabs on a member server is imo more easy then the AD DC. 


The "force sync" 
samba-tool drs replicate DEST SOURCE DN --full-sync is what i have in mind. 
So you can since the best database to the other servers. 


> 
> > 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
> 
> --
> Mit freundlichen Grüßen, / Best Regards, Sven Schwedas, 
> Systemadministrator Mail/XMPP sven.schwedas at tao.at | Skype 
> sven.schwedas TAO Digital | Lendplatz 45 | A8020 Graz 
> https://www.tao-digital.at | Tel +43 680 301 7167


Greetz, 

Louis




More information about the samba mailing list