15
Kein Zugriff möglich auf Win8-PCs (RDP, DCOM, C) in ActiveDirectory
Hallo,
Ist-Zustand:
Die Server wurdne bereits vor 1,5 Jahren von SBS 2003 auf SBS 2011 migriert.
Alle System sind mit aktuellen Patches versehen. Alle Arbeitsplätze können normal genutzt werden.
Serverfreigaben, Gruppenrichtlinien, Drucker..etc. funktionieren.
Problem:
Ich bekomme von den Servern (oder von anderen Arbeitsplätzen) keinen Zugriff auf die Windows-8-Arbeitsplätze.
Es sieht für mich so aus also ob alle Ports geblockt werden:
- Kein Zugriff auf RDP (z.B. mit telnet x.x.x.x 3389)
- Kein Zugriff auf DCOM, Port 135 (resultierend: etliche Einträgen im EreignisProtokoll mit Event 10009)
- Kein Zugriff auf Administrative Freigaben (C$) -> Fehler: 53 = Netzwerkpfad nicht gefunden
- teilweise kein Ping möglich. manchmal funktioniert es.. !?
Diese Probleme tauchen in allen möglichen Varianten auf:
Win8 PC -> Win8 PC
Server1 -> Win8 PC
Server2 -> Win8 PC
Ein Zugriff auf die Windows 7 Systeme ist immer möglich.
Zusätzlich dauern die Anmeldevorgänge an die Arbeitsstationen sehr lange (~ 3 Minuten).
Was habe ich bisher gemacht / geprüft:
Erstellungszeitpunkt: 07/29/2013 09:30:22
Ereigniszeichenfolge: DCOM konnte mit dem Computer "PCXX.Domain.local" unter Verwendung eines
beliebigen, konfigurierten Protokolls keine Daten austauschen.
Trotzdem ist ein Telnet x.x.x.x 3389 von einem anderen PC nicht möglich...
Die PC-Systeme hatten bisher WindowsXP. Ich habe dort jeweils eine komplette Win8-Neuinstallation vorgenommen (ohne die Systeme vorher aus der Domäne zu nehmen). Den Rechnernamen habe ich beibehalten. Nach erfolgter Installation habe ich die Rechner wieder der Domäne hinzugefügt.
War das vielleicht eine falsche Vorgehensweise ?
Ich hoffe mir kann jemand helfen..
DANKE
Grüße
Ist-Zustand:
| Windows Server SBS 2011 (2 Server) | 192.168.2.2 / 192.168.2.4 |
| Router | 192.168.2.1 |
| Windows 8 Arbeitsplätze, 10 Stück | 192.168.2.2XX |
| Windows 7 Arbeitsplätze, 3 Stück | 192.168.2.2XX |
Die Server wurdne bereits vor 1,5 Jahren von SBS 2003 auf SBS 2011 migriert.
Alle System sind mit aktuellen Patches versehen. Alle Arbeitsplätze können normal genutzt werden.
Serverfreigaben, Gruppenrichtlinien, Drucker..etc. funktionieren.
Problem:
Ich bekomme von den Servern (oder von anderen Arbeitsplätzen) keinen Zugriff auf die Windows-8-Arbeitsplätze.
Es sieht für mich so aus also ob alle Ports geblockt werden:
- Kein Zugriff auf RDP (z.B. mit telnet x.x.x.x 3389)
- Kein Zugriff auf DCOM, Port 135 (resultierend: etliche Einträgen im EreignisProtokoll mit Event 10009)
- Kein Zugriff auf Administrative Freigaben (C$) -> Fehler: 53 = Netzwerkpfad nicht gefunden
- teilweise kein Ping möglich. manchmal funktioniert es.. !?
Diese Probleme tauchen in allen möglichen Varianten auf:
Win8 PC -> Win8 PC
Server1 -> Win8 PC
Server2 -> Win8 PC
Ein Zugriff auf die Windows 7 Systeme ist immer möglich.
Zusätzlich dauern die Anmeldevorgänge an die Arbeitsstationen sehr lange (~ 3 Minuten).
Was habe ich bisher gemacht / geprüft:
- dcdiag zeigt "nur" DCOM-Probleme:
Erstellungszeitpunkt: 07/29/2013 09:30:22
Ereigniszeichenfolge: DCOM konnte mit dem Computer "PCXX.Domain.local" unter Verwendung eines
beliebigen, konfigurierten Protokolls keine Daten austauschen.
- SYSVOL-Replizierung funktioniert
- DNS-Konfiguration der Clients erscheint mir korrekt und Probleme tauchen auch bei Benutzung der IP-Adressen auf:
| ip | 192.168.2.2XX |
| gateway | 192.168.2.1 |
| dns 1 | 192.168.2.2 |
| dns 2 | 192.168.2.4 |
| mask | 255.255.255.0 |
- Gruppenrichtlinien werden verteilt / angewendet.
- Alle PCs sind in der richtigen OU (MyBusines\Computers\SBSComputers)
| TCP | 0.0.0.0:3389 | 0.0.0.0:0 | ABHÖREN |
| TCP | [::]:3389 | [::]:0 | ABHÖREN |
| UDP | 0.0.0.0:3389 | *:* | |
| UDP | [::]:3389 | *:* |
Die PC-Systeme hatten bisher WindowsXP. Ich habe dort jeweils eine komplette Win8-Neuinstallation vorgenommen (ohne die Systeme vorher aus der Domäne zu nehmen). Den Rechnernamen habe ich beibehalten. Nach erfolgter Installation habe ich die Rechner wieder der Domäne hinzugefügt.
War das vielleicht eine falsche Vorgehensweise ?
Ich hoffe mir kann jemand helfen..
DANKE
Grüße
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: 212768
Url: https://administrator.de/forum/kein-zugriff-moeglich-auf-win8-pcs-rdp-dcom-c-in-activedirectory-212768.html
Ausgedruckt am: 23.12.2024 um 16:12 Uhr
15 Kommentare
Neuester Kommentar
Hallo,
bei Win8 wude einiges bezüglich der Firewalls überarbeitet, was von vornherrein geblockt wird...
GPO und dann die Benötigten vordefini9erten Services freigeben, vor allem für das Domänennetzwerk und an den vordefenierten Reglen nix ändern, dann gehts danach auch.
Auf die C$ Freigaben kommst Du übrigens nur als DER Administrator, Domänen-Admin Mitgleidschaft reicht nicht.
Gruß
Chonta
bei Win8 wude einiges bezüglich der Firewalls überarbeitet, was von vornherrein geblockt wird...
GPO und dann die Benötigten vordefini9erten Services freigeben, vor allem für das Domänennetzwerk und an den vordefenierten Reglen nix ändern, dann gehts danach auch.
Auf die C$ Freigaben kommst Du übrigens nur als DER Administrator, Domänen-Admin Mitgleidschaft reicht nicht.
Gruß
Chonta
@Chonta
Grüße,
Dani
Auf die C$ Freigaben kommst Du übrigens nur als DER Administrator, Domänen-Admin Mitgleidschaft reicht nicht.
Ist das eine Neuerung von Windows 8 bzw. Server 2012? Funktioniert unter Windows 7 Professional und Server 2008R2 problemlos.Grüße,
Dani
Hallo Chonta,
Die GPO sind entsprechend zugewiesen: z.B. "Windows SBS Client - Windows 8 Policy"
Was meinst Du mit vordefinierten Services ?
Der benutzer User ist Mitflied von "Domäne\Administratoren"
ich hatte auch testweise die Client-Firewall komplett deaktiviert... ohne das sich etwas geändert hat.
Grüße
hopinor
Die GPO sind entsprechend zugewiesen: z.B. "Windows SBS Client - Windows 8 Policy"
Was meinst Du mit vordefinierten Services ?
Der benutzer User ist Mitflied von "Domäne\Administratoren"
ich hatte auch testweise die Client-Firewall komplett deaktiviert... ohne das sich etwas geändert hat.
Grüße
hopinor
Moin Dani.
Funktioniert unter Windows 7 Professional und Server 2008R2 problemlos.
Nein, das funktioniert keineswegs problemlos. Seit Vista muss zum Funktionieren ein Registryeintrag gesetzt werden: http://www.jimmah.com/vista/Networking/filtertoken.aspx
Moin,
nur zu meinem Verständnis. Du betreibst ZWEI SBS2011 in einem Netzwerk?
Viele Grüße
nur zu meinem Verständnis. Du betreibst ZWEI SBS2011 in einem Netzwerk?
Viele Grüße
Hallo,
Nein, das Netzwerk hat 2 Server:
DC 1 = Windows SBS 2011, Exchange 2010..etc.
DC 2 = Windows 2008 R2, SQL...etc.
Grüße
Nein, das Netzwerk hat 2 Server:
DC 1 = Windows SBS 2011, Exchange 2010..etc.
DC 2 = Windows 2008 R2, SQL...etc.
Grüße
Nehme alles zurück und behaupte das Gegenteil.
Bin eben im Test auf eine Administrative Freigabe raufgekommen.
Aber ich hatte vor einer weile auch die Firewalleinstellungen angepasst und davor ging es nur mit Administrator.
Gruß
Chonta
Bin eben im Test auf eine Administrative Freigabe raufgekommen.
Aber ich hatte vor einer weile auch die Firewalleinstellungen angepasst und davor ging es nur mit Administrator.
Gruß
Chonta
Moin DWW,
leuchtet mir an sich ein... trotzdem funktion der Zugriff auf C$-Freigaben bei uns mit Domänen-Admin-Rechten. Wir haben laut unser Doku nicht nachgeholfen
Grüße,
Dani
leuchtet mir an sich ein... trotzdem funktion der Zugriff auf C$-Freigaben bei uns mit Domänen-Admin-Rechten. Wir haben laut unser Doku nicht nachgeholfen
Grüße,
Dani
Halo Dani, DWW
Soweit ich das verstanden habe, ist die LocalAccountTokenFilterPolicy nur bei Arbeitsgruppen notwendig, nicht bei Domänen.
Grüße
hopinor
Soweit ich das verstanden habe, ist die LocalAccountTokenFilterPolicy nur bei Arbeitsgruppen notwendig, nicht bei Domänen.
Grüße
hopinor
Genauer: es ist nur bei lokalen Nutzern (egal ob der PC Domänenmitglied ist, oder nicht) entscheidend, nicht bei Domänenkonten. Das war bei Vista früher noch anders (siehe Knowledgebaseartikel), mir scheint, das hat MS mit einem SP geändert.
Egal. Hat mit Deinem Problem eh nichts zu tun, denn das ist auf Netzwerkebene. Prüfe bitte, ob Du per gekreuztem Kabel auf 3389 mit telnet kommst (kannst natürlich auch den selben Switch nutzen).
Egal. Hat mit Deinem Problem eh nichts zu tun, denn das ist auf Netzwerkebene. Prüfe bitte, ob Du per gekreuztem Kabel auf 3389 mit telnet kommst (kannst natürlich auch den selben Switch nutzen).
Hallo DWW,
was soll das mit dem gekreuzten Kabel bringen ?
Die Systeme haben ja Zugriff auf Serverfreiagben, Internet..etc.
Grüße
hopinor
was soll das mit dem gekreuzten Kabel bringen ?
Die Systeme haben ja Zugriff auf Serverfreiagben, Internet..etc.
Grüße
hopinor
Damit kannst Du ausschließen, dass es "auf dem Weg" ein Netzwerkproblem gibt.
Du hast mit netstat an der Quelle festgestellt, dass 3389 offen ist. Wenn Du Dich aber mit telnet nicht auf 3389 verbinden kann, muss ja etwas unterwegs passieren.
Du hast mit netstat an der Quelle festgestellt, dass 3389 offen ist. Wenn Du Dich aber mit telnet nicht auf 3389 verbinden kann, muss ja etwas unterwegs passieren.
Hallo DWW,
Vielen Dank für die Antwort, aber es kann doch gar nicht am Kabel liegen.
wenn read und write vertauscht wären, warum auch immer, hätte ich doch gar keine Funktion.
Alle PC's waren bereits vorher mit derselbern Infrastruktur und WinXP im Einsatz.
Mal abgesehen davon, dass ich das Problem mit jedem Win8-Pc und mit keinem anderen habe..
Grüße
Vielen Dank für die Antwort, aber es kann doch gar nicht am Kabel liegen.
wenn read und write vertauscht wären, warum auch immer, hätte ich doch gar keine Funktion.
Alle PC's waren bereits vorher mit derselbern Infrastruktur und WinXP im Einsatz.
Mal abgesehen davon, dass ich das Problem mit jedem Win8-Pc und mit keinem anderen habe..
Grüße
Am Kabel? Das schrieb ich auch nicht.
Wenn ein Port am Rechner offen ist, aber nicht angetelnettet werden kann, dann stimmt was unterwegs nicht, was denn sonst. Um das also herauszufinden, hält man den Kommunikationsweg so simpel wie möglich und testet - so lange, bis man wieder alle Wegstrecken wie vorher benutzt und damit wahrscheinlich die Problemstrecke/Switch/Firewall ausmachen kann.
Wenn ein Port am Rechner offen ist, aber nicht angetelnettet werden kann, dann stimmt was unterwegs nicht, was denn sonst. Um das also herauszufinden, hält man den Kommunikationsweg so simpel wie möglich und testet - so lange, bis man wieder alle Wegstrecken wie vorher benutzt und damit wahrscheinlich die Problemstrecke/Switch/Firewall ausmachen kann.
Hi,
Problem ist gelöst...Es lag an einer Gruppenrichtlinie in der die Firewalleinstelungen gesetzt wurden.
Obwohl ich das bereits mehrfach überprüft hatte, war folgender Fehler vorhanden:
Die erlaubten, eingehenden Regeln lassen sich beschränken auf z.B. das lokale Netzwerk.
Dafür muss ein Feld mit "localsubnet" gefüllt werden. Tja, und wenn man da dann " localsubnet"
(mit führendem Leerzeichen) reinschreibt, wird gar keiner zugelassen...
Das muss man erstmal finden, insbesonders weil "netstat -an" den Listener ja auch anzeigt...
Nun ist alles gut.
Danke an alle
Problem ist gelöst...Es lag an einer Gruppenrichtlinie in der die Firewalleinstelungen gesetzt wurden.
Obwohl ich das bereits mehrfach überprüft hatte, war folgender Fehler vorhanden:
Die erlaubten, eingehenden Regeln lassen sich beschränken auf z.B. das lokale Netzwerk.
Dafür muss ein Feld mit "localsubnet" gefüllt werden. Tja, und wenn man da dann " localsubnet"
(mit führendem Leerzeichen) reinschreibt, wird gar keiner zugelassen...
Das muss man erstmal finden, insbesonders weil "netstat -an" den Listener ja auch anzeigt...
Nun ist alles gut.
Danke an alle
