Während du als Privatanwender mit einer ganz gewöhnlichen Windows 10 oder 11-Installation bestimmt nicht auf Probleme mit dem sogenannten Active Directory stoßen wirst, sieht das im Unternehmensumfeld oft anders aus. Active Directory ist Microsofts zentrale Datenbank und dient in erster Linie der Speicherung und Verwaltung von Computern, Benutzern und anderen Objekten. Herzstück dieses Dienstes ist der Domänencontroller, der in manchen Fällen für zahlreiche Probleme verantwortlich sein kann. Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto für diese Vertrauensstellung? Oder die konkrete Arbeitsstation? Dann befindest du dich mit großer Sicherheit in einem Unternehmensnetzwerk und es gibt im Grunde nur drei Akteure, die dieses Problem verursachen können. Entweder dein Rechner oder der Domänencontroller. Oder irgendetwas dazwischen, wie etwa die LAN- oder Internetverbindung. Wir erklären dir in unserem kleinen Guide, wie du wieder auf dein Benutzerkonto zugreifen kannst und beginnen zuerst mit den offensichtlicheren Störenfrieden.
Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto: Benutzerkonto (aus Versehen) auf dem Rechner gelöscht?
Es ist nicht ganz unmöglich, dass das Computerkonto aufgrund eines Fehlers in einem Skript bei der Anmeldung oder einer Automatisierung versehentlich gelöscht wurde. Oder du hast vielleicht selbst den Kontonamen geändert oder gar dein Konto gelöscht. Entweder, weil du dein Betriebssystem neu installiert oder aufgefrischt hast, oder weil beispielsweise Probleme mit deinen Benutzereinstellungen auftraten – Gründe dafür gibt es viele. Wenn dein Benutzerkonto nun aber fehlt und du auf die Nutzung einer Domäne angewiesen bist, kann dein Rechner keine Verbindung mehr zur Domäne herstellen.
Folgend wird die Fehlermeldung „Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto“ angezeigt. Um das Problem zu lösen, gilt es, das Konto wiederherzustellen oder ein neues zu erstellen. Mit entsprechenden Rechten kannst du das in der Active Directory-Benutzerverwaltungskonsole (ADUC) oder mit PowerShell-Befehlen erledigen. Bist du aber nicht der Administrator, wende dich am besten direkt an diesen.
Während du gelöschte lokale Benutzerkonten in der Regel einfach neu erstellen kannst (und dabei aber sämtliche Benutzereinstellungen neu festlegen musst), ist das bei Serverkonten etwas schwieriger. Hier musst du nun unterscheiden, ob du dich auf dem betroffenen Client befindest oder Zugang zum Server hast. Bist du auf der Seite des Clients, hast du nicht so gute Karten. Du kannst aber versuchen, nach Möglichkeit ein Backup einzuspielen, um auszuschließen, dass das Problem auf deinem lokalen Rechner verursacht wird.
Bist du der Administrator des Domänencontrollers, hast du an dieser Stelle wesentlich mehr Freiheiten. Manchmal ist nämlich lediglich ein abgelaufenes Konto Schuld an der Misere. Das passiert häufig bei externen Mitarbeitern oder Personen, die nur für einen ganz bestimmten Zeitraum im Unternehmen tätig sind. Wird dann ein Arbeits- oder Dienstvertrag verlängert und das Ablaufdatum nicht geändert, blickt der User spätestens nach dem Stichtag in die leere Röhre – oder auf ein temporäres lokales Konto.
Abgelaufenes Benutzerkonto auf dem Rechner oder im Active Directory
Benutzerkonten im Unternehmensumfeld besitzen normalerweise ein Ablaufdatum, nach welchem entweder eine Verlängerung seitens des Administrators erfolgt oder du zumindest dein Kennwort ändern musst. Ist das Konto abgelaufen oder wurde gar deaktiviert, kann dein Rechner keine Verbindung mehr zur Domäne herstellen und du landest am Ende auch in diesem Fall bei dieser Fehlermeldung. Um das Problem zu lösen, kannst du versuchen, dein Benutzerkonto zu reaktivieren. Du benötigst dafür entweder die Active Directory-Benutzerverwaltungskonsole oder rufst direkt die PowerShell auf, indem du im Startmenü danach suchst. Vergiss aber nicht, das Tool als Administrator auszuführen, du benötigst hier nämlich alle Rechte, die du kriegen kannst. Im Idealfall bist du hier am besten direkt auch der Admin – da dieser ansonsten nicht so gelassen auf deinen „Workaround“ reagieren wird.
Auf dem Server kannst du direkt über das Startmenü die „Windows-Verwaltungsprogramme“ aufrufen und dort auf die „Active Directory-Benutzer und -Computer“ doppelklicken. Klappe in der linken Spalte nun die gewünschte Domäne aus und öffne den Ordner „Users“. Doppelklicke anschließend auf den betroffenen Benutzer und wechsle in die Registerkarte „Konto“. Prüfe an dieser Stelle sämtliche Einträge auf ihre Korrektheit:
- Stelle sicher, dass im Abschnitt „Konto läuft ab“ entweder ein Datum in der Zukunft eingetragen ist oder „Nie“ ausgewählt ist.
- Prüfe außerdem über einen Klick auf den Button „Anmeldezeiten“, ob die Uhrzeiten den tatsächlichen Arbeitszeiten entsprechen. Ist hier beispielsweise ein Zeitraum deaktiviert, kann sich der Nutzer in diesem nicht anmelden.
- Vielleicht sind auch noch weitere Einschränkungen aktiv, sodass sich der Nutzer nur auf bestimmten Rechnern im Netzwerk anmelden kann. Prüfe das über den Button „Anmelden an“ und füge dort gegebenenfalls weitere Rechnernamen hinzu.
Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto wegen eines Vertrauensproblems mit dem Domänencontroller
Wenn die Vertrauensstellung zwischen dem Client-Computer und dem Domänencontroller unterbrochen ist, kann der Client-Computer keine Verbindung zur Domäne herstellen und es wird in diesem Fall häufig die Fehlermeldung „Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto für diese Arbeitsstationsvertrauensstellung“ angezeigt. Die Vertrauensstellung kann aus verschiedenen Gründen unterbrochen werden, wie etwa durch Änderungen an den DNS-Einstellungen oder an den Active Directory-Settings. Oder einfach nur, weil du gerade irgendwo im Ausland unterwegs bist und entweder gar keine Verbindung zum Unternehmensnetzwerk aufbauen kannst oder das Geoblocking der Firewall dich nicht hineinlässt. Um das Problem zu lösen, musst du in der Regel einfach nur die Vertrauensstellung zwischen dem Client-Computer und dem Domänencontroller wiederherstellen – entweder mit der ADUC oder über die PowerShell.
Du kannst hier entweder versuchen, den betroffenen Rechner temporär aus der Domäne zu entfernen und danach wieder hinzuzufügen. Oder du setzt das Client-Passwort auf dem Domänencontroller zurück. Tippe dafür in der PowerShell folgenden Befehl ein und bestätige mit der [EINGABETASTE]:
Reset-ComputerMachinePassword -Server SERVERNAME -Credential DOMÄNE\BENUTZER
Wobei du die Variablen in Großbuchstaben an deine Umgebung anpassen und, sollte sich ein Leerzeichen in deinem Benutzernamen befinden, diesen mit einem Anführungszeichen umschließen musst.
Jetzt kannst du im Anmeldefenster erneut die Anmeldedaten für dein Benutzerkonto eingeben und dadurch in der Regel das Vertrauensproblem lösen.
Keine Verbindung mit der Domain beziehungsweise dem Domänencontroller
Wenn der Client-Computer nicht mit der Domäne verbunden ist, kann dieser selbstredend auch keine Verbindung herstellen. Als Folge wird die Fehlermeldung „Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto“ angezeigt. Überprüfe an dieser Stelle die Netzwerkeinstellungen auf dem Client-Computer. Stelle dabei sicher, dass dein Rechner mit dem richtigen Domänencontroller verbunden ist und dass die DNS-Einstellungen korrekt sind. Überprüfe ferner, ob das Benutzerkonto in der Domäne überhaupt vorhanden und nicht abgelaufen oder deaktiviert ist. In der Regel liegt dem Problem aber einfach eine nicht vorhandene Netzwerkverbindung zugrunde. Das kann mehrere Gründe haben:
- Keine verfügbare Netzwerkverbindung
- Zu schwache WLAN-Signalstärke und dementsprechend häufige Verbindungsabbrüche
- Fehlerhafte Konfiguration auf dem Client-Gerät (wie beispielsweise falsches WLAN-Passwort, fehlende DNS-Einstellungen)
- Netzwerkfehler im Unternehmensnetzwerk oder außerhalb (etwa auch Ausfälle auf Seite des Providers)
- Hardwareprobleme am Client-Gerät
- Einschränkungen auf dem genutzten Netzwerk (zum Beispiel blockierte Verbindungen oder wenn Anmeldedaten erforderlich sind)
- Softwarefehler auf dem Client-Gerät wie etwa Viren, Malware und Trojaner
Prüfe auf jeden Fall sämtliche der genannten Punkte, bevor du mit der Fehlersuche auf dem Domänencontroller beginnst. In der Regel sind es nämlich meist Kleinigkeiten, die große Probleme verursachen.
Bestehendes Problem mit der Active Directory Datenbank
Es ist außerdem nicht ganz unmöglich, dass ein Problem mit der Active Directory-Datenbank vorliegt, das dazu führt, dass dein Benutzerkonto und möglicherweise auch viele weitere nicht gefunden werden können. Überprüfe in so einem Fall zuerst einmal die Ereignisprotokolle auf dem Domänencontroller, um festzustellen, ob es Probleme mit der Datenbank gibt, die die Fehlermeldung verursachen könnten. Sind Fehler oder Unstimmigkeiten protokolliert worden, ist es notwendig, entweder die Datenbank zu reparieren oder, die meist schnellere Variante, ein Backup einzuspielen.
Möchtest du aber trotzdem eine Reparatur versuchen, gilt es zuerst, in den Verzeichnisdienst-Wiederherstellungsmodus zu wechseln. Bei neueren Server-Versionen von Microsoft Windows erreichst du diesen über die erweiterten Starteinstellungen. Suche dafür im Startmenü nach „Wiederherstellung“ und klicke im Abschnitt „Erweiterter Start“ auf den Button „Jetzt neu starten“. Gib optional einen Grund für den Neustart an (wenn deine Richtlinien das erfordern) und klicke abschließend auf „Weiter“. Jetzt werden dir in Kürze mehrere Startoptionen angezeigt. Vielleicht kommt dir der Screen bereits vom Abgesicherten Modus bekannt vor. Diesen erreichst du nämlich über denselben Weg.
Domänen-Recovery per Eingabeaufforderung
Wähle anschließend „Verzeichnisdienste-Wiederherstellungsmodus“ warte, bis der Rechner wieder hochgefahren ist. Melde dich mit einem Administratorkonto an und öffne die Eingabeaufforderung, indem du im Startmenü danach suchst. Achte darauf, diese als Administrator auszuführen, da dir ansonsten die Rechte für diesen Eingriff fehlen. Gib anschließend folgende Befehl ein, wobei du den Pfad gegebenenfalls abändern musst – je nachdem, wo sich deine Active Directory Datenbank befindet:
esentutl /g C:\windows\NTDS\ntds.dit /!10240 /8 /o
Bestätige die Befehle jeweils mit der [EINGABETASTE] und warte, bis die nun laufende Integritätsprüfung abgeschlossen ist. Werden dir hier fehlerhafte Dateien oder Einträge angezeigt, die sich in Form der Fehlermeldung „Ergebnisse beschädigt,-1206“ manifestieren, gib im nächsten Schritt
esentutl /p C:\Winnt\NTDS\ntds.dit /!10240 /8 /o
ein, um einen sogenannten Hard-Reset der Active Directory Datenbank durchzuführen. Dieser Vorgang kann etwas Zeit in Anspruch nehmen und setzt die Datenbank auf den Zustand der zuletzt durchgeführten Transaktion zurück. Wurde seitdem eine weitere Transaktion durchgeführt, könnte diese verloren gehen. Aus diesem Grund ist es immer sinnvoller, lieber ein vollständiges Backup aus der (hoffentlich) täglichen Sicherung einzuspielen.
Abschließend kannst du den Server wieder neu starten, um den Verzeichnisdienst-Wiederherstellungsmodus wieder zu verlassen.
Doppelte Rechnernamen im Netzwerk
Zugegeben, die Wahrscheinlichkeit ist nicht so groß, wie du vielleicht denkst, aber es kann in seltenen Fällen vorkommen, dass sich zwei identische Rechnernamen in ein und demselben Netzwerk befinden. Das endet in der Regel ähnlich wie bei einem IP-Adressenkonflikt, nämlich so, dass ein Rechner nicht auf das Netzwerk zugreifen, beziehungsweise sich nicht an der Domäne anmelden kann.
Du arbeitest womöglich mit virtuellen Maschinen und hast eine VM geklont? Natürlich hast du hier auch den Computernamen mitgeklont. Genauso verhält sich das, wenn du zum Beispiel ein Backup auf einen neuen Rechner aufspielst, der alte aber immer noch in Betrieb ist. Und die Liste griechischer Götter- oder deutscher Städtenamen ist auch nicht endlos lang, sodass auch bei diesen häufig genutzten Namensschemata irgendwann der Punkt erreicht ist, an dem sich zwei identische Namen begegnen.
Das ist auch noch gar kein Problem, wenn du direkt auf den betroffenen Rechner zugreifen und dort den Namen ändern kannst. Öffne hierfür einfach die Systemeigenschaften, indem du das Ausführen-Bedienfeld mit [WINDOWS] + [R] aufrufst. Gib dort sysdm.cpl ein, bestätige mit der [EINGABETASTE] und klicke im Systemeigenschaften-Fenster auf den Ändern-Button. Dort kannst du jetzt nicht nur den Computernamen ändern, sondern gegebenenfalls auch noch einmal die Domäne checken. Fehlt dort nämlich der entsprechende Eintrag, könnte das Problem auch hiervon ausgehen. Bestätige anschließend mit einem Klick auf „OK“ und starte deinen Rechner neu, um den neuen Namen im Netzwerk zu übernehmen.
Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto – möglicherweise aufgrund einer nicht mehr unterstützten Windows-Server-Version
Ein wenig Nostalgie im lokalen Firmennetzwerk, weil früher ja alles besser war, kann ja nicht schaden, oder? Nicht selten kommt es vor, dass der Führungsetage die Probleme, die veraltete Software mit sich bringen kann, bekannt und bewusst sind. Bist du als Administrator deshalb in der Situation, dich mit Uralt-Serverversionen herumzuschlagen, kann unsere besagte Fehlermeldung auch eine Art Weckruf für alle sein, endlich auf ein neueres Betriebssystem zu setzen. Nutzt du beziehungsweise dein Arbeitgeber nämlich etwa noch Windows Server 2003, die Clients sind aber bereits mit Windows 10 oder gar 11 unterwegs, sind Inkompatibilitäten auf jeden Fall vorprogrammiert.
Server-Timeout bei der Nutzung mehrerer Domänencontroller
Während du bei lediglich einem Unternehmensstandort in der Regel auch nur einen Domänencontroller nutzt, existieren ein paar Szenarien, in denen dein Unternehmen vielleicht mehrere dieser Art einsetzt. Etwa dann, wenn mehrere Standorte weltweit miteinander vernetzt werden und gleichzeitig eine gewisse Redundanz sichergestellt sein soll. In so einem Fall kann es vorkommen, dass aus diversen Gründen ein Domänencontroller über einen bestimmten Zeitraum nicht reagiert und deshalb für die zukünftige Replikation gesperrt wird. Das Resultat: Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto mehr.
In der Regel handelt es sich hier aber um einen sehr üppig ausgelegten Zeitraum, je nach Version zwischen 60 und 180 Tagen. Aus diesem Grund ist es eher unwahrscheinlich, dass dir der Ausfall erst auffällt, wenn damit zusammenhängende Benutzerkonten ihre Gültigkeit verlieren. Gerade aber bei virtuellen Testumgebungen kann das häufiger vorkommen – weil du beispielsweise die VM zum Testen neuer Updates oder Features ein paar Monate lang nicht benötigt hast.
Replikation manuell starten
Kam es bereits zu einer Überschreitung der sogenannten Tombstone-Time (Verfallszeit), kannst du die Replikation manuell über einen kleinen Workaround anstoßen. Zuvor solltest du aber sichergehen, dass alle involvierten Domänencontroller über ein Backup verfügen, nur für den Fall der Fälle. Öffne auf dem betroffenen Server anschließend den Registrierungseditor und navigiere zu folgendem Schlüssel, um die Replikation mit bereits abgelaufenen Servern zu erlauben:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\nTDS\Parameters\Allow Replication With Divergent and Corrupt Partner
Doppelklicke darauf und korrigiere den Wert auf 1. Wechsle im nächsten Schritt zum Schlüssel
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistency
und setze diesen auf 0, um die Richtlinien für die Konsistenzprüfung zu lockern. Vergiss aber nicht, die Werte wieder auf den vorherigen Stand zu setzen, wenn du mit deiner Operation fertig bist.
Synchronisation und Prüfung anstoßen
Jetzt fehlen nur noch eine Synchronisierung und abschließende Prüfung. Bedenke aber, dass diese Vorgehensweise nur dann funktioniert, wenn der betroffene Server immer noch Domänendienste ausführt. Ist das nicht der Fall, nörgelt die Konsole, dass keine weiteren Endpunkte verfügbar sind oder der Stammserver nicht auffindbar ist. Rufe die PowerShell über das Startmenü auf und gib dort folgende zwei Befehle, gefolgt von der [EINGABETASTE] ein:
repadmin /syncall /APde (startet die Synchronisierung) repadmin /replsummary (zeigt dir eine Zusammenfassung über das Synchronisierungsergebnis an)
Hinweis: Wir raten dir dringend davon ab, diese Registrierungsänderung auf weiteren Domänencontrollern durchzuführen. Ändere die Werte lediglich auf jenem Server, der für den Fehler Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto verantwortlich ist und ändere diese nach erfolgter Replikation wieder auf die ursprünglichen Einträge zurück.
