IPSec und kein Ende in Sicht !

[ccwurm 10]

Die Serverrichtlinie (Request Security) lässt unverschlüsselte Initialkommunikation zu und antwortet mit einer Sicherheitsaushandlung. Wird diese nicht beantwortet , weil der Client IPSec nicht beherrscht oder keine zugewiesene Richtlinie hat, wird unverschlüsselt kommuniziert. Da Dein Client aber eine Antwortrichtlinie hat (er wird niemals von selbst versuchen, eine verschlüsselte Verbindung herzustellen, sondern antwort ausschliesslich auf Sicherheitsaushandlungen), diese aber nicht funktioniert, schlägt diese Verbindung fehl. Entfernst Du die Zuweisung auf dem Client, sollte es klappen ...

 

Was ist jetzt wenn der Server die Sicherheitsrichtlinie Server Require Security aktiviert hat? Dann läßt er doch keine unverschlüsselte Initialkommunikation mehr zu, oder? Was bedeutet, der Client benötigt die Server Request Security Richtlinie um überhaupt noch mit dem Server kommunizieren zu können (dann halt nur noch verschlüsselt). !?! Oder hab ich das jetzt durcheinander gebracht?

[ChristianHemker 10]

Wenn der Server vorschreibt (Require), muss der Client eine von den 3 IPSec Richtlinien aktiviert haben. Welche ist für die Kommunikation zwischen diesen beiden egal.

Wenn du möchtest dass der Client mit anderen Clients unverschlüsselt kommuniziert, nimmst du Client (Nur Antwort). Dann kann er mit dem Server kommunizieren, baut aber mit anderen Rechnern keine IPSec Verbindung auf, die das nicht wollen (Require oder Request).

 

Wichtig ist immer nur, dass die sich gegenseitig authentifizieren können. Die Standard IPSec Richtlinien nutzen dafür Kerberos, was natürlich in einer Arbeitsgruppe nicht geht. Für einen Test würde ich einfach einen vorinstallierten Schlüssel verwenden, für eine Produktivumgebung Zertifikate.

[IThome 10]

Ja genau, die Frage war, warum bei zugewiesener Server (Sicherheit anfordern) Richtlinie und Client (nur Antwort) Richtlinie (beide Richtlinien sind mit Kerberos Auth konfiguriert) der Client nicht mit dem Server kommunizieren kann, obwohl der Server ja eigentlich unverschlüsselt kommunizieren kann. Weil der Server auf die unverschlüsselte Anfrage mit einer Sicherheitsaushandlung antwortet und von dem Client eine (falsche) Antwort erhält. Es kommt überhaupt keine Verbindung zustande ...

[ccwurm 10]

@ChristianHemker

 

Alles klar.

Also initiiert ein Rechner mit der aktivierten Richtlinie Client (nur Antwort) niemals von sich aus eine verschlüsselte Verbindung. Wenn ich also z.B. möchte, dass ein Client verschlüsselt kommuniziert und trotzdem noch z.B. einem anderen Client die verschlüsselste Kommunikation anbietet, dann aktiviere ich beim Client die Regel Server (Sicherheit Anfodern). Wenn ich möchte, dass er grundsätzlich mit allen anderen verschüsselt kommuniziert, dann aktiviere ich die Regel Server (Sicherheit erforderlich) am Client.

 

Ist doch richtig oder? :suspect: ;)

[IThome 10]

Das ist soweit korrekt. Konfigurierst Du die Richtlinie Server (Sicherheit anfordern), kann dieser Host mit jedem kommunizieren, der entweder keine IPSec-Richtlinie zugewiesen hat, der kein IPSec benutzen kann, der eine IPSec-Richtlinie zugewiesen hat und die Einstellungen für Authentifizierung, Verschlüsselung usw. passen zur konfigurierten Richtlinie. Er kann nicht mit einem Host kommunizieren, der z.B. die Client (nur Antwort) Richtlinie zugewiesen hat , dessen Einstellungen für Authentifizierung usw. unterschiedlich sind. Wenn also Richtlinien zugewiesen wurden, müssen sie passen, auch wenn die Richtlinie Server (Sicherheit anfordern) auch eine unverschlüsselte Kommunikation eigentlich zulässt (aber nur mit Clients, die nicht auf die Sicherheitsaushandlung antworten)

Ist die Richtlinie Server (Sicherheit erforderlich) konfiguriert, ist nur noch Kommunikation zu solchen Hosts möglich, die eine passende IPSec-Richtlinie konfiguriert und zugewiesen haben .

[Thyral 10]

@all

Alles soweit gut und schön, aber eine Frage habe ich da doch noch !!

 

Ich habe eine CA installiert, ich kann Webseiten mit Cert aufrufen, emails verschlüsseln, praktisch alles !!

 

Ausser !!!! IP-Sec mit meiner eigenen CA verschlüsseln. Warum taucht meine CA nicht in der Liste der vertrauenswürdige Stammzertifizierungsstelle in IPSec auf.

 

Wenn ich bei IPSec auf eine richtlinie gehe und dort die Authentifizierung und dann verwenden eines Zertifikats... auf durchsuchen, da ist meine Stelle nicht vorhanden.

 

in der MMC Zertifikate ist sie vorhanden und auch alles gültig.

 

Wo habe ich was vergessen ?

 

THX

[ChristianHemker 10]

Warum taucht meine CA nicht in der Liste der vertrauenswürdige Stammzertifizierungsstelle in IPSec auf.

Auf welchem Rechner taucht es nicht auf?

Hat der Client schon ein Zertifikat?

[Thyral 10]

Hallo,

 

nein, der Benutzer hat noch kein Zertifikat. Hat es damit zu tun ? Weil die CA kann ich aufrufen !! Es ist ein Client ausserhalb der Domäne.

[ChristianHemker 10]

Fordere für den Client doch mal ein Computerzertifikat an.

[ccwurm 10]

Sorry, ich verwende jetzt mal diesen Thread, da es bei mir auch um ipsec geht...

 

Ich bin noch am Verzweifeln...

 

Habe zwei Rechner (ein DC und eine Mitgliedsserver). Beide in derselben Domäne, beide Windows Server 2003. Habe über Gruppenrichtlinien auf den DC die IPSec Richtlinie Server (request security) angewendet und ebenfalls über Gruppenrichtlinien auf den Mitgliedsserver die IPSec Richtlinie Client (response only) angewendet. Der IP-Sicherheitsmonitor bestätigt mir die aktiven Richtlinien auf den Rechnern. Bei Ping von einem zum anderen Rechner geht es kurzzeitig (ca. 2 Antworten kommen zurück), dann ist's vorbei mit der ICMP-Kommunikation. Eine anschließende Telnet Session ist auch nicht funktionstüchtig.

 

Im IP-Sicherheitsmonitor wird keine Sicherheitszuordnung aufgeführt und im EventLog steht auch nichts von einer Sicherheitsaushandlung.

 

Habe das gleiche Szenarion (gleiche IPSec Richtlinien) hier bei uns in der Domäne ausprobiert (mit zwei Workstations), gleiches Ergebnis.

 

Habe dann in meiner Testumgebung von Kerberos Authentifizierung auf Vorinstallierter Schlüssel umgestellt, jetzt krieg ich im IP-Sicherheitsmonitor eine Sicherheitszuordnung zu sehen, aber Ping (ICMP) ist wieder nicht möglich, wobei die Telnet-Session jetzt funktioniert.

 

ICMP sollte eigentlich ohne jegliche Verschlüsselung durchgelassen werden, so ist es zuminest in der Server (request security) Richtlinie eingestellt.

 

Weiter oben im Thread wird auf die verschiedenen IPSec Richtlinien eingegangen, ich dachte eigentlich verstanden zu haben, dass die Client (response only) gründsätzlich dafür geeignet ist, mit der Server (request security) und der Secure Server (require security) Richtlinie verschlüsselt zu kommunizieren?

 

Ich wäre echt dankbar, wenn sich jemand mit meinem Problem auseinandersetzen könnte.

Danke!!

 

ccwurm

[Thyral 10]

@ccwurm

 

Das Problem hatte und habe ich auch immernoch, einmal klappt es einmal nicht, dann denkt man es ist logisch, dann kommt wieder keine Verbindung zu stande.

Aber hier bist du ganz richtig, die Leute werden dir mit Sicherheit helfen, ich werde mich einhängen unddadurch versuchen eine echte logik zu entwickeln.

 

Also, wenn ich zwei Clients habe, stelle ich eine IPSec Richt ein mit Schlüssel, weil es dort keine Kerberos authe. gibt, das ist klar.

Wenn ich eine AD habe und die Cleints innerhalb der AD arbeiten, dann greift kerberos und alles klappt auch wieder innerhalb des Sicherheitsrandes der AD.

Wenn ich in AD und externe Clients habe, dann nehme ich Zertifikate zur authen. wegen das sicherste Mittel.

 

soweit die Theorie, wenn ich einmal server einschalte und einmal client , dann sollte es verschlüsselt sein. Klappt, aber leider auch nicht immer.

 

Vieleicht bringen deine Fragen und meine Antworten etwas licht ins dunkel.

 

Was ich in der Testumgebung gemerkt habe ist, dass man die Zeiten zum generieren neue schlüssel runterstellen sollte, denn sonst kommt auch keine verbindung zu stande.

[ChristianHemker 10]

ICMP sollte eigentlich ohne jegliche Verschlüsselung durchgelassen werden, so ist es zuminest in der Server (request security) Richtlinie eingestellt.

 

Weiter oben im Thread wird auf die verschiedenen IPSec Richtlinien eingegangen, ich dachte eigentlich verstanden zu haben, dass die Client (response only) gründsätzlich dafür geeignet ist, mit der Server (request security) und der Secure Server (require security) Richtlinie verschlüsselt zu kommunizieren?

Von der Theorie her sollte es funktionieren, mit deinen beiden Richtlinien. Allerdings ist es in den Standardrichtlinien wirklich so, dass PING unverschlüsselt durchgelassen werden sollte. Daher wundert es mich schon sehr, dass es 2x funktioniert und danach gar nicht mehr. Gibt er beim Pingen auch zuerst die Meldung "Negotiating IP Security" aus?

[ccwurm 10]

@ChristianHemker

 

Nein macht er nicht.

[ChristianHemker 10]

Dann wird PING auch nicht verschlüsselt.

Auf dem Zielrechner sollte mithilfe des Netzwerkmonitors also ICMP und nicht ESP zu sehen sein.

Das wäre dann völlig normal, da Ping ja in den Standardrichtlinien nicht verschlüsselt wird.

[ccwurm 10]

So, habe jetzt nochmal im Internet gegoogelt und viel rumprobiert. Microsoft schreibt in einem Artikel in der TechNet (hab den Link jetzt leider nicht mehr), dass die Client (response only) Richtlinie grundsätzlich für die verschlüsselte Kommunikation sowohl mit der Server (request security) als auch mit der Secure Server (require security) Richtlinie verwendet werden kann. Einfach deshalb, weil beide eine unverschlüsselte Eingangskommunikation zulassen und anschließend Sicherheit aushandeln. Die Secure Server (require security) Richtlinie bietet halt kein fallback auf unverschlüsselte Kommunikation.

 

Naja, das habe ich auch nochmal in meiner Testumgebung nachgestellt. Sowohl Client <-> Server als auch Client <-> Secure Server. Bei beiden hat die Kommunikation problemlos funktioniert. Lediglich der Ping ist nach Zuweisung der Richtlinien untereinander nicht mehr möglich. Sobald ich die Sicherheitsregel "ICMP Datenverkehr -> zulassen" abwähle, funktioniert auch der Ping untereinander wieder. Wahrscheinlich, weil dieser dann auch verschlüsselt abgehandelt wird und es somit keine Probleme mehr gibt.

 

ich denke halt mittlerweile, dass die beiden Stationen nach Aushandlung der Sicherheit, untereinander keinerlei unverschlüsselte Kommunikation mehr zulassen, auch keinen Ping (ICMP). Ganz einfach deshalb, weil ja die Verschüsselung der ganzen IP-Pakete auch die ICMP-Pakete miteinschließt. Warum diese Sicherheitsregel dann allerdings bei den Sicherheitsrichtlinien definiert ist, kann ich nicht verstehen?

 

P.S.: Ich werde versuchen, mir das ganze demnäscht nochmal mit dem Netzwerkmonitor anzusehen.

 

ccwurm