carlito

Schau mal in den Eigenschaften der LAN-Verbindung in die Erweiterten TCP/IP-Einstellungen im Register 'WINS'. Welche Haken sind dort gesetzt?

Wieso hat der Client IP-Routing aktiviert? Weshalb fungiert der Client als Bridge?

Implizite Benutzergruppen? Bezüglich Materialmangel: hast du diese beiden Artikel schon gelesen? Gruppenarten in Windows http://www.winfaq.de/faq_html/tip1147.htm Verwendung von Gruppentypen und -bereichen in Windows 2000 http://support.microsoft.com/default.aspx?scid=kb;de;231273

Verwendest du Zertifikate? Sind diese auch auch dem XP Client installiert?

Ich würde die Liste um Domänen-Lokale und Universelle Gruppen erweitern. Das kommt darauf an, welche Zielgruppe du hast.

Task-Manager in Verbindung mit 'netstat'?

Bist du sicher, das es ein Angriff ist? Ich würde erstmal auf einen (neuen) Konfigurationsfehler tippen. Denn unabhängig davon wüsste ich spontan nicht, was diese Art von Angriff bringen sollte - wenn es überhaupt ein Angriff ist.

Als Alternative probiere es mal mit zwei Subnetzen. Siehe hier: http://www.mcseboard.de/showthread.php?t=57764

Warum trägst du bei der LAN-Verbindung keinen GW und DNS ein? Desweiteren gibt es bei der WLAN-Verbindung die Möglichkeit, den Bridge Modus zu aktivieren. Vielleicht hilft dir das weiter...

Es gibt Gruppenrichtlinienergebnisse und Gruppenrichtlinienmodellierung. Mit ersterem überprüft man die tatsächlich wirkenden GPOs, mit letzterem simuliert man (was wäre wenn). Ersteres setzt also vorraus, das der zu testende User schon in den entsprechenden Gruppen ist, unterhalb der gewünschten OUs steht etc. Ist das bei dir der Fall?

Ein Angriff über ICMP? 'Destination Unreachable' ist klar, aber wie kann jemand von außen einen Ping auf eine interne IP absetzen? Das führt doch zu nichts, es sei denn auf dem Router läuft NAT in beide Richtungen!?

Geht es um RIS oder allgemein um PXE und TFTP?

Falls es überall die gleichen Netzwerkkarten sind, würde ich in der Registry suchen, ob es einen entsprechenden Schlüssel gibt. Diesen Eintrag exportieren und dann per Skript bzw. GPO auf den Clients ausführen. Das nur so also Idee...

ASUS P2B DS(?) Ist das Onboard SCSI? Vielleicht ein Treiber Problem bzw. ein Problem bei der Erkennung von Plug and Play Hardware?

Also der Rechner hat zwei LAN-Verbindungen: einmal per Kabel und einmal per WLAN, richtig? Kopiere mal den Output von 'ipconfig /all' und 'route print' hier rein.

Auf dem WLAN Access Point läuft ein DHCP Server? Übermittelt dieser auch den DNS Server deines Providers (den du vom ISP bekommst) an den Client?

Hast du es mal mit einer Remotedesktop Konsolensitzung probiert?

Dazu habe ich zwei Vorschläge: 1. Möglichkeit Verwendung von Klassenkennungen. Dabei wird zwischen Hersteller- und Benutzerklassen unterschieden. Die Clients müssen entsprechend konfiguriert werden (ipconfig /setclassid) und senden dann bei ihrer DHCP Anforderung diese Klassenkennung mit. Wenn der DHCP Server mit der gleichen Klassenkennung konfiguriert ist, bekommen diese Clients eine DHCP Konfiguration zugewiesen. Clients, die keine Klassenkennung mitsenden, sollten keine IP-Konfiguration vom DHCP Server bekommen. 2. Möglichkeit Switches mit IEEE 802.1x Unterstützung. Installiere einen RADIUS bzw. IAS Server und konfiguriere Zertifikate auf den Clients, die für die LAN-Verbindung (Eigenschaften -> Authentifizierung) verwendet werden. Stelle die Switches entsprechend ein, so das diese einen RADIUS Server zur Authentifizierung verwenden. Somit ist sichergestellt, das nur Clients, auf denen entsprechende Zertifikate installiert sind, eine Verbindung mit dem Switch (und somit dem Netzwerk, in dem der DHCP Server angeschlossen ist) herstellen können. Ich persönlich würde es mit der ersten Methode versuchen, da das zweite Verfahren weitaus aufwendiger ist und auch entsprechende Hardware vorrausetzt.

Danke für die Info. Das würde dann auf eine eigene passfilt.dll hinauslaufen, wie in dem MS KB Artikel beschrieben, richtig?

Meinst du vielleicht diesen Artikel: http://support.microsoft.com/kb/151082/en-us Das bezieht sich zwar auf NT, aber vielleicht kannst du ja die eine oder andere Information rausholen.

Gemacht habe ich das noch nicht, aber ich würde mal einen Blick in die %Systemroot%\System.adm werfen und schauen, ob und wie ich daraus evtl. eigene Kennwort-Richtlinien ableiten könnte.

Wenn du es unbedingt so haben willst wäre mein Tipp eine benutzerdefinierte ADM Vorlage.

Auf der Microsoft Website habe ich das auch so gelesen, aber ich meine bei VUE stand, das diese Aktion nur für VUE Prüfungen gilt. Ich werde nochmal genau nachlesen...

Du bist direkt an der Server-Konsole? Funktioniert der Zugriff auf http://localhost/? Wenn ja, dann probiere http://localhost/SUSAdmin/. Klappt es vielleicht per HTTPS anstelle von HTTP?

Spielt der Proxy-Server eine Rolle bei diesem Problem? Als welcher Benutzer versucht du die Verbindung zum SUS-Server heruzustellen? Hast du an den Standard-Berechtigungen der Website etwas geändert?