Ich habe mir die Sache heute noch mal etwas gründlicher angesehen.
Ich sage mal, mein Posting von Gestern traf den Kern nicht.
Dem Kerberos sind solche Umkopier- oder Verlagerungsaktionen egal, sofern er nicht selber davon betroffen ist. Kerberos wirkt auch nicht auf solche Aktionen ein und verhindert z. B. Operationen mit Dateitypen “.dll” oder so.
Zumindest nicht ohne weiteres.
Zum besseren Verständnis mal kurz die Wirkung eines Kerberos im System (keine Angst, ich mache es wirklich kurz, dafür soll mir dann aber auch keiner kommen, ich hätte diesen und jenen Aspekt weggelassen…):
Prinzipiell besteht ein Mini - Kerberos aus drei Komponenten, einem Admin - Server, einem “Key Distribution Center” (KDC) und einem Client. Admin - Server kann es nur einen geben (verwaltet die zentrale, netzwerkweite DB mit den Usern / Passwörtern), dieser kann gleichzeitig auch als KDC fungieren (in größeren Netzen hat man wegen Performance / Ausfallsicherheit mehrere aktiv, mitunter sogar in größeren Domänen) und mindestens einem Client. Ohne Client macht so etwas eigentlich keinen Sinn…
Stark vereinfacht dargestellt nimmt der Kerberos die Anmeldeinformationen des Users am System entgegen und erstellt / verwaltet für diesen User Zertifikate, mit denen dieser gegenüber Diensten und Anwendungen authentifiziert - aber nicht autorisiert - wird.
Damit braucht es nur noch eine Anmeldung am System, um andere - normalerweise passwortgeschützte - Aktionen durchführen zu können.
Soviel zum Kerberos. Wer also autorisiert ist, bestimmte Prozesse zu starten, braucht sich dafür nicht mit einem neuen Passwort anzumelden. Was der User darf, wird aber nach wie vor durch die Rechteverwaltung bestimmt. Umgekehrt kann übrigens der Kerberos so administriert werden, dass sich auch Dienste zertifizieren müssen: dafür ist die pg aber vorbereitet: sie müsste irgendwo - vermutlich im “bin - Verzeichnis” - eine Datei wie “krb5.dll” oder so haben (aktuell verbreitetste Version des Kerberos).
Damit kann der Kerberos nicht der “Schuldige” sein: wer kopieren und Server umdeklarieren darf, der kann es auch mit laufendem Kerberos…
Worauf der Kerberos allerdings ziemlich empfindlich reagiert, sind Probleme mit dem zentralen Zeitgeber. Die vom Kerberos erstellten Zertifikate haben nur eine begrenzte Lebensdauer, die bei großzügigen Einstellungen Stunden betragen, normalerweise eher weniger. Ein “Läuft nie ab” würde ja auch dem Sinn in keinster Weise entsprechen. Ist im normalfall auch kein Problem: durch die Synchronisation der Server und die Überwachung durch den Kerberos wird bei noch andauernder Nutzeraktivität rechtzeitig ein neues Zertifikat angefordert.
Dabei kann es dann passieren (ist mir passiert), dass ein unter Vollast laufender Server die Synchronisation mit dem zentralen “Zeitverteiler” einstellt und diese vor Ablauf des Zertifikates nicht wieder aufgenommen hat. Dann wird das Zertifikat nach Ablauf verworfen, wird der Nutzer von den nicht mehr von einem gültigen Zertifikat “gedeckten” Aktivitäten (Dienste / Anwendungen) abgemeldet.
Werden die Abweichungen in den “Systemzeiten” zu groß, kann davon auch mal der ganze Server betroffen sein - sofern kritische Dienste zur Zertifizierung gezwungen wurden.
Die dabei auftretenden Fehler äußern sich aber ganz anders. Ein Kopiervorgang beispielsweise bleibt “hängen” oder bricht ab, ich kann auf einen Server zwar noch über eine Laufwerksverbindung zugreifen, die Remote - Console gibt keinen Mucks mehr von sich oder so.
Eigentlich sollte es dann eine qualifizierte Fehlermeldung geben, aber… 
Ich habe mir heute die Zeit genommen, mal einen KDC zum Client und einen Client zum KDC zu machen - an den Admin - Kerberos bin ich aus gutem Grund nicht ´ran. Die Konfigurationen sind unterschiedlich, Kerberos verlangt erheblich mehr als nur ein paar dll´s, um wieder zu arbeiten. Und beeinträchtigt / beeinflusst ansonsten laufende Programme nicht.
Sorry, aber ihr müsst euch, so wie es aussieht, einen anderen “Schuldigen” suchen.