8
Bitlocker - Remoteendpunkt war nicht erreichbar
Moin Moin,
heute mal eine Frage zum Thema Laufwerksverschlüsselung/ Bitlocker.
Wir befinden uns im Livetest von Bitlocker und nun tritt bei einem Client leider der Fehler "Der Remoteendpunkt war nicht erreichbar" auf.
Bei den anderen Clients wird die Festplatte ohne Probleme verschlüsselt.
Zur Info:
Auf einem Server befindet sich der IIS mit den "Bitlocker Portal".
Die Konfiguration wird über eine GPO verteilt und soweit auch von allen Clients, welche sich im Livetest befinden übernommen.
Auch die mitgegebene URL in der Konfiguration kann ohne Probleme aufgerufen werden.
Dennoch meldet der eine Client immer "Der Remoteendpunkt war nicht erreichbar" während die anderen Clients die Verschlüsselung starten.
Ereignispfad: "Ereignisse\Anwendungs- und Dienstprotokolle\Microsoft\Windows\MBAM"
Genaue Fehlermeldung:
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-MBAM" Guid="{1C6E854B-3DF3-4A6F-9401-F58F1D1C504D}" />
<EventID>18</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2015-03-04T11:59:08.215542200Z" />
<EventRecordID>497</EventRecordID>
<Correlation />
<Execution ProcessID="14028" ThreadID="14076" />
<Channel>Microsoft-Windows-MBAM/Admin</Channel>
<Computer>### FQDN des Clients ###</Computer>
<Security UserID="S-1-5-18" />
</System>
- <EventData>
<Data Name="ErrorCode">0x803d0010</Data>
<Data Name="ErrorString">Der Remoteendpunkt war nicht erreichbar.</Data>
</EventData>
</Event>
Google hatte bis jetzt auch noch keine passende Antwort dazu.
Ich hoffe, dass hier einer eine Idee zu dem Thema hat.
Besten Dank
heute mal eine Frage zum Thema Laufwerksverschlüsselung/ Bitlocker.
Wir befinden uns im Livetest von Bitlocker und nun tritt bei einem Client leider der Fehler "Der Remoteendpunkt war nicht erreichbar" auf.
Bei den anderen Clients wird die Festplatte ohne Probleme verschlüsselt.
Zur Info:
Auf einem Server befindet sich der IIS mit den "Bitlocker Portal".
Die Konfiguration wird über eine GPO verteilt und soweit auch von allen Clients, welche sich im Livetest befinden übernommen.
Auch die mitgegebene URL in der Konfiguration kann ohne Probleme aufgerufen werden.
Dennoch meldet der eine Client immer "Der Remoteendpunkt war nicht erreichbar" während die anderen Clients die Verschlüsselung starten.
Ereignispfad: "Ereignisse\Anwendungs- und Dienstprotokolle\Microsoft\Windows\MBAM"
Genaue Fehlermeldung:
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-MBAM" Guid="{1C6E854B-3DF3-4A6F-9401-F58F1D1C504D}" />
<EventID>18</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2015-03-04T11:59:08.215542200Z" />
<EventRecordID>497</EventRecordID>
<Correlation />
<Execution ProcessID="14028" ThreadID="14076" />
<Channel>Microsoft-Windows-MBAM/Admin</Channel>
<Computer>### FQDN des Clients ###</Computer>
<Security UserID="S-1-5-18" />
</System>
- <EventData>
<Data Name="ErrorCode">0x803d0010</Data>
<Data Name="ErrorString">Der Remoteendpunkt war nicht erreichbar.</Data>
</EventData>
</Event>
Google hatte bis jetzt auch noch keine passende Antwort dazu.
Ich hoffe, dass hier einer eine Idee zu dem Thema hat.
Besten Dank
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 265205
Url: https://administrator.de/contentid/265205
Ausgedruckt am: 26.11.2024 um 00:11 Uhr
8 Kommentare
Neuester Kommentar
Hi.
Du nutzt MBAM. In wieweit kann MBAM denn mit dem PC kommunizieren? Ist ausgeschlossen, dass es sich um Konnektivitätsprobleme handelt? Welche Ports nutzt MBAM? Hast Du mit telnet deren Erreichbarkeit geprüft?
Du nutzt MBAM. In wieweit kann MBAM denn mit dem PC kommunizieren? Ist ausgeschlossen, dass es sich um Konnektivitätsprobleme handelt? Welche Ports nutzt MBAM? Hast Du mit telnet deren Erreichbarkeit geprüft?
Hey,
danke für deine Antwort... habe allerdings paar Verständnisfragen:
1) In wieweit kann MBAM denn mit dem PC kommunizieren?
Was genau meinst du damit? :p
Auf den Clients ist halt der MBAM Client installiert, welcher seine Konfiguration via. GPO erhält.
2) Ist ausgeschlossen, dass es sich um Konnektivitätsprobleme handelt?
Da ich nicht genau weiß wie MBAM/BitLocker den "Remoteendpoint" kontaktiert, kann ich das pauschal nicht beantworten.
Ich habe halt gelesen, dass die beiden Adressen aus der Konfiguration erreichbar sein müssen.
Das wären:
a) KeyRecoveryServiceEndPoint
b) StatusReportingServiceEndPoint
Auf beide URLs welche für die Reg-Schlüssel hinterlegt sind, kann vom betroffenen Client ohne Problme übern Browser zugegriffen werden.
3) Welche Ports nutzt MBAM? Hast Du mit telnet deren Erreichbarkeit geprüft?
Kann ich so auch nicht beantworten. Kann ich morgen aber natürlich mal prüfen... wäre ein Anhaltspunkt.
Danke.
Wie gesagt: Ich hatte heute einen anderen Client genommen, und dieser hat ohne zu zögern das Notebook verschlüsselt.
Also muss ja irgendwas lokal an dem blöden Notebook die Kommunikation blockieren bzw. dafür sorfen, dass die Kommunikation nicht statt finden kann.
So meine Vermutung aktuell.
UPDATE: 21:02
Telnet meldet keine Fehler für Port 443.
Das ist der Port, der für die URL gilt. Halt HTTPS Verbindung.
danke für deine Antwort... habe allerdings paar Verständnisfragen:
1) In wieweit kann MBAM denn mit dem PC kommunizieren?
Was genau meinst du damit? :p
Auf den Clients ist halt der MBAM Client installiert, welcher seine Konfiguration via. GPO erhält.
2) Ist ausgeschlossen, dass es sich um Konnektivitätsprobleme handelt?
Da ich nicht genau weiß wie MBAM/BitLocker den "Remoteendpoint" kontaktiert, kann ich das pauschal nicht beantworten.
Ich habe halt gelesen, dass die beiden Adressen aus der Konfiguration erreichbar sein müssen.
Das wären:
a) KeyRecoveryServiceEndPoint
b) StatusReportingServiceEndPoint
Auf beide URLs welche für die Reg-Schlüssel hinterlegt sind, kann vom betroffenen Client ohne Problme übern Browser zugegriffen werden.
3) Welche Ports nutzt MBAM? Hast Du mit telnet deren Erreichbarkeit geprüft?
Kann ich so auch nicht beantworten. Kann ich morgen aber natürlich mal prüfen... wäre ein Anhaltspunkt.
Danke.
Wie gesagt: Ich hatte heute einen anderen Client genommen, und dieser hat ohne zu zögern das Notebook verschlüsselt.
Also muss ja irgendwas lokal an dem blöden Notebook die Kommunikation blockieren bzw. dafür sorfen, dass die Kommunikation nicht statt finden kann.
So meine Vermutung aktuell.
UPDATE: 21:02
Telnet meldet keine Fehler für Port 443.
Das ist der Port, der für die URL gilt. Halt HTTPS Verbindung.
1) In wieweit kann MBAM denn mit dem PC kommunizieren?
Was genau meinst du damit? :p
Hey,
das ist er auch...
Ich hatte gestern Abend noch einmal etwas getestet:
Ich habe für den Dienst "BitLocker Management Client Service" die Anmeldeinformation von "lokales System" auf meinen Domain-Admin Account geändert. Anschließend habe ich die Meldung "Successfully connected to the MBAM Recovery and Hardware service." erhalten. Soweit so gut.
Jetzt stell ich mir halt die Frage, wieso mein Client nicht mit den default Einstellungen mit dem Server kommunizieren kann, die anderen Clients aber schon.
Falls du da auch noch eine Idee zu hättest, wäre das klasse :p
das ist er auch...
Ich hatte gestern Abend noch einmal etwas getestet:
Ich habe für den Dienst "BitLocker Management Client Service" die Anmeldeinformation von "lokales System" auf meinen Domain-Admin Account geändert. Anschließend habe ich die Meldung "Successfully connected to the MBAM Recovery and Hardware service." erhalten. Soweit so gut.
Jetzt stell ich mir halt die Frage, wieso mein Client nicht mit den default Einstellungen mit dem Server kommunizieren kann, die anderen Clients aber schon.
Falls du da auch noch eine Idee zu hättest, wäre das klasse :p
Leider keine Idee. Ich würde jedoch von der Verwendung des Domänenadmins dafür stark abraten - niemals einen Domänenadmin für Dienste nehmen, zu unsicher!
Wenn an dem Rechner nichts anders ist, riecht das ja nach einem Problem auf der Serverseite, aber da ist vermutlich alles einheitlich eingestellt, oder? Keine Ahnung, ich habe mir MBAM erspart und alles mit Skripten gelöst.
Wenn an dem Rechner nichts anders ist, riecht das ja nach einem Problem auf der Serverseite, aber da ist vermutlich alles einheitlich eingestellt, oder? Keine Ahnung, ich habe mir MBAM erspart und alles mit Skripten gelöst.
Das war auch lediglich, um den Fehler eingrenzen zu können.
Mhh, ok such mal weiter.
Falls ich noch eine Lösung finde, werde ich sie hier posten.
Mhh, ok such mal weiter.
Falls ich noch eine Lösung finde, werde ich sie hier posten.
Also ich habe jetzt noch einmal mit dem Process Monitor von Sysinternals und Wireshark etc. versucht, den Fehler zu finden.
Mit Netstat -no 1 | find "Prozessnummer(PID) von MBamAgent" habe ich sehen können, dass der Agent immer eine Loopback-Verbindung auf den Port 55457 aufbauen möchte. Die Zeile sieht dann wie folgt aus:
netstat -no 1 | find "6032"
TCP 127.0.0.1:49876 --> 127.0.0.1:55457 SYN_GESENDET --> 6032
Gut,
Der Agent versucht also eine Loopback-Verbindung zu erstellen.
Er sendet auch ein SYN-Paket. Wieso kommt die Verbindung nicht zu stande?
Wireshark hat mir leider keine Infos zur Loopback Verbindung angezeigt. Also habe ich das Programm "RawCap" heruntergeladen und mit dem Befehl "RawCap.exe 127.0.0.1 dumpfile.pcap" mit den Datenverkehr der Loopback-Verbindung anzeigen lassen. Mit Wireshark lässt sich die Datei dann öffnen und lesen.
Hier sehe ich, dass, was netstat mir auch schon angezeigt hat...
Port 49876 --> 55457 [SYN] Seq=0 Win=8192 Len=0 Mss=65459 WS=256 SACK_PERM=1
Also SYN gesendet...
Jetzt kommt die Antwort auf das Paket:
Port 55457 --> 49876 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
Wenn ich mir das Paket im Detail anschaue, sehe ich das im TCP\IP Flag das RESET: Set bit auf 1 gesetzt ist und das Security level auf "Warning" steht.
Nun muss ich gestehen, dass ich kein Netzwerkmokel bin, und an dieser Stelle definitiv nicht weiterkomme. Ich hoffe, dass meine Interpretation des Datenverkehrs richtig ist.
Falls noch einer eine Idee zu dem Verhalten hat, wäre ich sehr sehr dankbar.
Besten Dank
Mit Netstat -no 1 | find "Prozessnummer(PID) von MBamAgent" habe ich sehen können, dass der Agent immer eine Loopback-Verbindung auf den Port 55457 aufbauen möchte. Die Zeile sieht dann wie folgt aus:
netstat -no 1 | find "6032"
TCP 127.0.0.1:49876 --> 127.0.0.1:55457 SYN_GESENDET --> 6032
Gut,
Der Agent versucht also eine Loopback-Verbindung zu erstellen.
Er sendet auch ein SYN-Paket. Wieso kommt die Verbindung nicht zu stande?
Wireshark hat mir leider keine Infos zur Loopback Verbindung angezeigt. Also habe ich das Programm "RawCap" heruntergeladen und mit dem Befehl "RawCap.exe 127.0.0.1 dumpfile.pcap" mit den Datenverkehr der Loopback-Verbindung anzeigen lassen. Mit Wireshark lässt sich die Datei dann öffnen und lesen.
Hier sehe ich, dass, was netstat mir auch schon angezeigt hat...
Port 49876 --> 55457 [SYN] Seq=0 Win=8192 Len=0 Mss=65459 WS=256 SACK_PERM=1
Also SYN gesendet...
Jetzt kommt die Antwort auf das Paket:
Port 55457 --> 49876 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
Wenn ich mir das Paket im Detail anschaue, sehe ich das im TCP\IP Flag das RESET: Set bit auf 1 gesetzt ist und das Security level auf "Warning" steht.
Nun muss ich gestehen, dass ich kein Netzwerkmokel bin, und an dieser Stelle definitiv nicht weiterkomme. Ich hoffe, dass meine Interpretation des Datenverkehrs richtig ist.
Falls noch einer eine Idee zu dem Verhalten hat, wäre ich sehr sehr dankbar.
Besten Dank
Moin Leute,
Lösung gefunden....
Bei mir war in der Registry für den Localsystem User in den IE Settings eine Proxy-Adresse mit dem Port 55457 eingetragen.
Diesen Schlüssel habe ich gelöscht, und nach einem Neustart wurde die Verbindung zum Bitlockerserver erfolgreich aufgebaut.
Also was bei einem solchen Fehler geprüft werden muss:
1) Registry als Admin öffnen
2) Zum Schlüssel navigieren (HKEY_USERS_\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings)
Hier existierte bei mir folgender Schlüssel:
ProxyServer | REG_SZ | http=127.0.0.1:55457;https:127.0.0.1:55457
Ich habe alle Schlüssel, die NICHT in das Verzeichnis gehören entfernt.
Somit dürften nur noch folgende Schlüssel existieren:
1) (Standard) | REG_SZ | (Wert nicht festgelegt
2) EnableNegotiate | REG_DWORD | 1
3) IE5_UA_Backup_Flag | REG_SZ | 5.0
4) ProxyEnable | REG_DWORD | 0
5) User Agent | REG_SZ | Mozilla/4.0 (compatible; MSIE 8.0; Win32)
6) ZonesSecurityUpgrade | REG_BINARY | * BINARY WERTE *
Nach einem Neustart sollte nun die Verbindung erfolgreich sein.
Ggf. auch die Einstellungen für den Benutzer S-1-5-19 prüfen.
Der Pfad sieht dann wie folgt aus:
HKEY_USERS_\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Dies war der Grund, weshalb ich in den IP-Dumps bzw. mit "Netstat -ano" den Port 55457 gesehen habe, und ich das [RST, ACK] erhalten habe.
Lösung gefunden....
Bei mir war in der Registry für den Localsystem User in den IE Settings eine Proxy-Adresse mit dem Port 55457 eingetragen.
Diesen Schlüssel habe ich gelöscht, und nach einem Neustart wurde die Verbindung zum Bitlockerserver erfolgreich aufgebaut.
Also was bei einem solchen Fehler geprüft werden muss:
1) Registry als Admin öffnen
2) Zum Schlüssel navigieren (HKEY_USERS_\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings)
Hier existierte bei mir folgender Schlüssel:
ProxyServer | REG_SZ | http=127.0.0.1:55457;https:127.0.0.1:55457
Ich habe alle Schlüssel, die NICHT in das Verzeichnis gehören entfernt.
Somit dürften nur noch folgende Schlüssel existieren:
1) (Standard) | REG_SZ | (Wert nicht festgelegt
2) EnableNegotiate | REG_DWORD | 1
3) IE5_UA_Backup_Flag | REG_SZ | 5.0
4) ProxyEnable | REG_DWORD | 0
5) User Agent | REG_SZ | Mozilla/4.0 (compatible; MSIE 8.0; Win32)
6) ZonesSecurityUpgrade | REG_BINARY | * BINARY WERTE *
Nach einem Neustart sollte nun die Verbindung erfolgreich sein.
Ggf. auch die Einstellungen für den Benutzer S-1-5-19 prüfen.
Der Pfad sieht dann wie folgt aus:
HKEY_USERS_\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Dies war der Grund, weshalb ich in den IP-Dumps bzw. mit "Netstat -ano" den Port 55457 gesehen habe, und ich das [RST, ACK] erhalten habe.
