Jeden Morgen das gleiche.. Vertrauensstellungsproblem

[Gregor Oelze]

Guten Morgen,

ich weiß nicht mehr weiter. Eine lange Zeit funktioniere unser Micrsoft-Server Konstrukt ohne größere Probleme, momentan scheint jedoch alles zusammenzubrechen:

Unser Setup:

WAN
|
Modem
|
Liss-Firwall-Appliance
|
IBM-XServer
(VMWare-ESXi)
- Server 1: 2008R2 DC, DHCP, DNS, GDATA-Console
- Server 2: 2008R2 Fileserver, Printserver
- Server 3: 2008R2 Exchange Server
- Server 4: 2008R2 Terminalserver
- Server 5: Ubuntu SSH-Server/Webserver (nicht in Domäne)
- Server 6: WinXP Testclient (in der Domäne)
- Server 7: 2008R2 Testmaschine (nicht in Domäne)
- Server 8: 2008R2 Sharepoint

Physikalisch
- Server 9: 2008R2 AD+FS für Windows-Sicherungen + AD-Replikation

Das Problem:
------------
Morgens können sich Clients an der Domäne anmelden. Die User arbeiten jedoch vor Allem auf dem Terminalserver. Wenn die User sich verbinden wollen kommt nach dem Anmeldefenster:

"Die Vertrauensstellung zwischen dieser Arbeitsstation und der Primären Domäne konnte nicht hergestellt werden."

Ich behelfe mir momentan damit, den Server 4 aus der Domäne zu nehmen und nach dem Neustart wieder in die Domäne zu heben, danach wieder ein Neustart und man kann arbeiten. Für einen Tag, maximal zwei Tage.

Interessanterweise ist das Computerkonto in der AD zu diesem Zeitpunkt deaktiviert.

Die Historie:
-------------
Wir hatten vor einiger Zeit mit diesem Setup schon einmal ein Problem mit unserem DC. Damals (ca. ein halbes Jahr) war der Server so defekt durch eine abgebrochene Sicherung, dass wir den DC wieder herstellen mussten aus einer Sicherung (Zeitunterschied: ca. 48 Stunden).

Wir konnten damals keine Maschine mehr anmelden an die Domäne. Nachdem wir einen Dienstleister auf das Problem angesetzt hatten versuchten diese ca. 8 Stunden lang den DNS wieder auf Vordermann zu bekommen um dann einen Microsoft-Case aufzumachen (am nächsten Tag). Ein Supporter von Microsoft schaltete sich dann auf den Server auf und setzte das Secure-Channel Kennwort zurück und nach einigen Neustarts ging alles wieder.

Nach dieser Zeit kam es jeden Monat vor, dass (meines Erarchtens nach, willkürlich) ein Server nach dem anderen nicht mehr mit der Domäne kommunizieren wollte: erst der Fileserver, dann der Exchange-Server. Jedoch ließ sich dieses Problem nicht durch ein "aus der Domäne in die Domäne" wieder herstellen sondern nur durch das erneute zurücksetzen des Securechannel-Passwortes.


Meine Mutmaßung:
-------------

Aufgrund der nachstehenen Ereignis IDs, sieht es so aus - als ob der Server 1 und Server 9 sich nicht miteinander unterhalten können aus Zugriffs/Berechtigungsproblemen, daher wird die AD nicht richtig repliziert und daher scheint es Vertrauensstellungsprobleme in der Domäne zu geben. Weiterhin sieht es so aus, als ob der Server 4 sich anstatt an Server 1 anzumelden, an Server 9 anmeldet. Die Frage ist wie das Problem zu beheben ist, bzw. für dieses und zukünfigte Netzwerke zu verhindern ist.


Offene Frage:
-------------
Gibt es Secure-Channel Technisch eine Art Wartung auf die man achten muss als Administrator in einem bestimmten Turnus? Ist das ein normales Verhalten eines Windows-Netzwerkes wenn man nicht bestimmte Tasks nach ca. einem halben Jahr / Jahr durchführt?

Wir haben noch mehrere andere Netzwerke in dieser Art aufgebaut und ich habe nun einfach nur Angst, dass sich diese Szenarien wiederholen und ich nicht weiß was ich tun kann, daher bin ich um jeden Denkanstoß oder Lösungsansatz dankbar. Daher: Vielen Dank im voraus,

beste Grüße

Gregor Oelze

PS: Um die Frage nach auftauchenden Eventlog-IDs zu beantworten:

Server 1: DC
-------------
Protokollname: System
Quelle: Microsoft-Windows-DistributedCOM
Datum: 16.03.2012 10:43:32
Ereignis-ID: 10009
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: Server 1
Beschreibung:
DCOM konnte mit dem Computer "Server 4.Domäne.local" unter Verwendung eines beliebigen, konfigurierten Protokolls keine Daten austauschen.
-------------
Protokollname: Directory Service
Quelle: Microsoft-Windows-ActiveDirectory_DomainService
Datum: 16.03.2012 10:42:18
Ereignis-ID: 1925
Aufgabenkategorie:Konsistenzprüfung
Ebene: Warnung
Schlüsselwörter:Klassisch
Benutzer: ANONYMOUS-ANMELDUNG
Computer: Server 1.Domäne.local
Beschreibung:
Fehler beim Herstellen einer Replikationsverknüpfung mit der folgenden schreibbaren Verzeichnispartition.

Verzeichnispartition:
(...)
Standortübergreifende Übertragung (falls vorhanden):


Dieser Verzeichnisdienst kann nicht mit dem Quellverzeichnisdienst replizieren, solange das Problem nicht behoben ist.

Benutzeraktion
Überprüfen Sie, ob auf den Quellverzeichnisdienst zugegriffen werden kann und ob eine Netzwerkverbindung besteht.

Zusätzliche Daten
Fehlerwert:
8453 Der Replikationszugriff wurde verweigert.
-------------
Protokollname: System
Quelle: Microsoft-Windows-Security-Kerberos
Datum: 16.03.2012 09:30:52
Ereignis-ID: 4
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: Server 1.Domäne.local
Beschreibung:
Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "Server 4$" empfangen. Der verwendete Zielname war cifs/Server4.Domäne.local. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, dass der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN bei dem Konto registriert ist, das vom Server verwendet wird, und zwar ausschließlich bei diesem Konto. Dieser Fehler kann auch auftreten, wenn der Zieldienst ein anderes Kennwort für das Zieldienstkonto verwendet als das Kennwort, das vom Kerberos-KDC (Key Distribution Center) für das Zieldienstkonto verwendet wird. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des aktuellen Kennworts aktualisiert wurden. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (GSG.LOCAL) von der Clientdomäne (GSG.LOCAL) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.
-------------


Server 4: Terminalserver
-------------
Protokollname: System
Quelle: Schannel
Datum: 15.03.2012 18:20:11
Ereignis-ID: 36888
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:
Benutzer: SYSTEM
Computer: Server 4.Domäne.local
Beschreibung:
Es wurde eine schwerwiegende Warnung generiert: 10. Der interne Fehlerstatus lautet: 10.
-------------
Protokollname: System
Quelle: LsaSrv
Datum: 15.03.2012 18:20:33
Ereignis-ID: 40961
Aufgabenkategorie:Keine
Ebene: Warnung
Schlüsselwörter:
Benutzer: Domäne\ml
Computer: Server 4.Domäne.local
Beschreibung:
Das Sicherheitssystem konnte keine sichere Verbindung mit dem Server LDAP/Server 9.Domäne.local/Domäne.local@Domäne.LOCAL herstellen. Es war kein Authentifizierungsprotokoll verfügbar.
Ereignis-XML:
-------------


Server 9: Backup-DC
-------------
Protokollname: Directory Service
Quelle: Microsoft-Windows-ActiveDirectory_DomainService
Datum: 16.03.2012 10:57:18
Ereignis-ID: 1699
Aufgabenkategorie:Replikation
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Domäne\Server 1$
Computer: Server 9.Domäne.local
Beschreibung:
Dieser Verzeichnisdienst konnte die Änderungen für die folgende Verzeichnispartition nicht erstellen. Der Verzeichnisdienst war daher nicht in der Lage, die Änderungsanforderung an den Verzeichnisdienst der folgenden Netzwerkadresse zu senden.

Verzeichnispartition:
DC=Domäne,DC=local
Netzwerkadresse:
17b62fd2-e2b4-42ac-a2c2-6e796fe89a44._msdcs.Domäne.local
Erweiterter Anforderungscode:
0

Zusätzliche Daten
Fehlerwert:
8453 Der Replikationszugriff wurde verweigert.
-------------

[xne...@gmail.com]

Hallo Gregor,

hast du hierzu eine Lösung gefunden? Wenn ja, kannst du diese Posten?

Beste Grüße
Norbert