Einen SBS 2003 außer Betrieb nehmen bzw. umziehen in eine „normale Dömanenstruktur“

Vor langer Zeit erschien es uns als gut einen SBS 2003 zu verwenden. OK. Es gibt Entscheidungen, die hat man getroffen und muss damit leben. Probleme gibt es eigentlich erst, wenn man alles anders machen will. 🙄

Wir wollten unseren SBS 2003 außer Betrieb nehmen und in eine normale Domäne umwandeln. Dazu alle Server virtualisieren etc. etc. Alles wurde neu eingerichtet, aber unser SBS 2003 war immer noch DER DC. Nachdem fast alle lebenswichtigen Dinge im Lauf der letzten Jahre und Monate schrittweise umgezogen waren, die mal auf der Kiste gelaufen sind (File-Server, Drucker-Server, Fax-Server, SQL-Sever, Exchange, RAS), blieb nur noch das AD übrig.

Nun einfach wäre es einen anderen Server als DC einzurichten kurz mal DCPromo aufrufen und gut ist es. Aber der SBS mag das ja gar nicht… 😳
Sobald der SBS einen anderen DC entdeckt, dauert es nicht lange und er fährt einfach herunter. Zuerst mal war ich etwas baff, als eine Kollegin sagte sie käme an ein paar alte Ordner nicht mehr heran. Als ich in den Server Raum ging musste ich feststellen, dass die Kiste einfach so ausgeschaltet herumsteht.
Ich rechnete mit Fehlermeldungen aber nicht mit einem brutalen Shutdown.
Dokumentiert ist das natürlich auch in der MSDN hier. ❗

Etwas Recherche im Netz brachte dann die vorübergehende Lösung, mit der ich bis zur kompletten Abschaltung dieses Servers weiterarbeiten konnte.
In Kürze geht man wie folgt vor:

  • Den Prozess C:\WINDOWS\system32\sbscrexe.exe mit dem Sysinternals Prozess Explorer suspenden. Abschießen geht nicht, denn der Prozess startet sich sofort neu.
  • Im Regedit dem Administratoren Rechte auf den Ast HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SBCore geben. Das geht auch nicht bei laufenden Dienst, denn der entzieht einem sofort die Rechte wieder.
  • Danach die Anzeige aktualisieren mit F5 damit die verborgenden Untereinträge sichtbar werden.
  • Nun das DWORD Start von 2 auf 4 ändern. Dadurch wird der Dienst deaktiviert und startet nicht erneut.
  • Neustart und das war es erstmal.

Die Beschreibung findet sich auch hier.

So das war Schritt 1 und nun ging es darum den AD von diesem Rechner zu entfernen.
Also mal eben wie geplant DCPromo aufgerufen um das AD von diesem Rechner zu entfernen. Es wäre zu schön gewesen, wenn das nun einfach gegangen wäre. DCPromo verweigerte den Dienst mit der folgenden Meldung:

Die Verwaltung der Netzwerksitzung mit Dem-Tollen-Neuen-Server ist fehlgeschlagen.
Das Netzlaufwerk ist nicht erreichbar. Weiter Informationen

😕 Ich hatte vergessen, das dieser Server immer noch einen DNS Dienst hatte und in den Einstellungen der Netzwerkkarte wurde dieser Server auch noch verwendet. Die Fehlermeldung ist natürlich nicht zielweisend, wie so oft leider. Nachdem ich den neuen DNS Server in der Netzwerkkarte eingetragen hatte lief der DCPromo klaglos durch und zurück blieb ein normaler Windows 2003 Server.

Nachdem auch die letzten Dateien gesichert bzw. umgezogen waren und der Streamer ausgebaut wurde steht da nur noch ein kilo-schwerer Schrotthaufen, der jahrelang klaglos seinen Job gemacht hat.

Alter Server

Eventlog Einträge mit der Ereigniskennung 675 im Sicherheit Ereignisprotokoll

Auf meinem Windows Server 2003 R2 haben sich in der letzten Zeit Fehlereinträge im Eventlog für die Sicherheit angehäuft. Und das bis zu 200 Einträge und mehr täglich.

Bei der Analyse stieß ich hauptsächlich auf die Ereigniskennung 675 mit dem Fehlercode 0x19. Meistens traten diese Eventlog Einträge im Viererpack auf, immer wenn ein Benutzer sich mit seinem PC im Netz angemeldet hat. Jeweils erschienen dann Einträge für den PC und den Benutzer, wie die nachfolgenden Beispiele beiden Beispiele aus dem Ereignisprotokoll meines Servers zeigen:

Ereignistyp: Fehlerüberw.
Ereignisquelle: Security
Ereigniskategorie: Kontoanmeldung
Ereigniskennung: 675
Datum: 21.04.2010
Zeit: 10:48:33
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: SERVER
Beschreibung:
Fehlgeschlagene Vorbestätigung:
  Benutzername: COMPUTER$
  Benutzerkennung: DOMAIN\COMPUTER$
  Dienstname: krbtgt/domain.loc
  Vorauthentifizierungstyp: 0x0
  Fehlercode: 0x19
  Clientadresse: 192.168.16.150

sowie:

Ereignistyp: Fehlerüberw.
Ereignisquelle: Security
Ereigniskategorie: Kontoanmeldung
Ereigniskennung: 675
Datum: 21.04.2010
Zeit: 10:48:52
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: SERVER
Beschreibung:
Fehlgeschlagene Vorbestätigung:
  Benutzername: Martin
  Benutzerkennung: DOMAIN\Martin
  Dienstname: krbtgt/DOMAIN
  Vorauthentifizierungstyp: 0x0
  Fehlercode: 0x19
  Clientadresse: 192.168.16.150

Nach einiger Recherche kam ich dahinter, dass dies nur Arbeitsplätze betraf, die Windows Vista oder Windows 7 einsetzten. Rechner mit Windows XP oder Windows 2003 Server tauchten hier nie auf.

Ein wenig weiteres Forschen brachte mich dann auf die Ursache:

Diese Event Id wird ausgegeben wenn, der Domänencontroller den Kerberos-Authentifizierungsversuch eines Rechners nicht versteht. Das nur Windows Vista und Windows 7 Rechner als Verursacher auftauchen liegt daran, dass mit Windows Vista AES (Advanced Encryption Standard) als Verschlüsselungsverfahren von den Clients bevorzugt wird.
Leider kennt aber der Windows 2003 Domänen-Controller dieses Verfahren noch nicht. Weil es aber einen Fallback auf das RC4-HMAC Verfahren gibt merkt der Anwender nichts davon.

Windows Systeme unterstützen die folgenden Verschlüsselungsverfahren für Kerberos:

  • DES-CBC-CRC (Registrycode 0x1)
  • DES-CBC-MD5 (Registrycode 0x3)
  • RC4-HMAC (Registrycode 0x17)
  • AES (Registrycode 0x12) Wird seit Windows Server 2008 unterstützt (d.h. auch Vista und Windows 7)

Die Standard Preauthentifizierung erfolgt bei Windows 2000, Windows Server 2003, Windows XP immer RC4-HMAC.

Die Lösung ist ein kleiner Workaround in dem man einfach dem Vista oder Windows 7 Rechner mitteilt er soll doch einfach auch die RC4-HMAC Verschlüsselung wählen. Das verhindert dann die Nutzung von AES  und die Fehler sind weg, die durch den vergeblichen AES Anmeldeversuch entstehen.
Das erreicht man in dem man den Code 0x17 (siehe Aufzählung oben) für den DefaultEncryptionType einträgt. Nachfolgend der entsprechende Auszug aus der REG-Datei, die ich auf die Clients verteilt habe.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"DefaultEncryptionType"=dword:00000017

Oder in anderen Worten gesagt:

  • Man startet Regedit an den betroffenen Clients
  • Man wählt den Ast HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Parameters
  • Dort erzeugt man einen DWORD Wert mit Namen DefaultEncryptionType
  • In diesen Wert setzt man 0x17 (bzw. 23 dezimal) ein

Nun ist Ruhe mit diesem Fehler 🙂

Weitere Links zum Thema Kerberos hier:
http://technet.microsoft.com/en-us/library/cc738673(WS.10).aspx
http://tools.ietf.org/html/rfc4757