25
802.1X-Authentifizierung
Hallo in die Runde,
ich bin Hobby-Admin und würde in meinem Netzwerk gern eine 802.1X-Authentifizierung einrichten. Dazu habe ich noch einige Fragen.
Ich habe in dem betreffenden Netz bereits einen RADIUS-Server unter W2k8-R1 zur Authentifizierung meiner drahtlosen Clients am Laufen. Nun würde ich gern einrichten, dass sich teilweise auch die drahtgebundenen Clients authentifizieren müssen.
Zuerst die wichtigste Frage - kann ich, wenn ich die Authentifizierung am Server über den RemoteDesktop an einem Client einrichte, mich selbst aussperren? Falls das eine blöde Frage ist, entschuldigt aber ich habe das noch nicht eingerichtet. Oder kann das nicht passieren, da vorher noch am Switch Konfigurationen notwendig sind?
Optimal wäre es, wenn man die Authetifizierung am Server einstellen kann und dann dem Switch sagen muss an welchen Ports authentifiziert werden soll - ist dass so??
Als Switche habe ich mehrere Cisco SG200 bzw. SG300 und SF300 im Einsatz.
Eine weitere Frage ist noch, ob die Authentifizierung auch in VLAN's erfolgen kann, die keine Verbindung zum Server haben. Die Frage ist so gemeint, dass in dem Netzwerk insgesamt 5 VLAN's existieren und alle natürlich zwar über die Switche laufen aber nur auf zwei davon der Server Zugriff hat. Theoretisch könnte doch aber auch hier ein Client durch den Switch über den RADIUS authentifiziert werden - oder??
Hat jemand eventuell noch einige Hinweise was zu beachten ist oder ist das in 5 Minuten eingerichtet?
Vielen Dank für Eure Hilfe im Voraus und viele Grüße
Alex
ich bin Hobby-Admin und würde in meinem Netzwerk gern eine 802.1X-Authentifizierung einrichten. Dazu habe ich noch einige Fragen.
Ich habe in dem betreffenden Netz bereits einen RADIUS-Server unter W2k8-R1 zur Authentifizierung meiner drahtlosen Clients am Laufen. Nun würde ich gern einrichten, dass sich teilweise auch die drahtgebundenen Clients authentifizieren müssen.
Zuerst die wichtigste Frage - kann ich, wenn ich die Authentifizierung am Server über den RemoteDesktop an einem Client einrichte, mich selbst aussperren? Falls das eine blöde Frage ist, entschuldigt aber ich habe das noch nicht eingerichtet. Oder kann das nicht passieren, da vorher noch am Switch Konfigurationen notwendig sind?
Optimal wäre es, wenn man die Authetifizierung am Server einstellen kann und dann dem Switch sagen muss an welchen Ports authentifiziert werden soll - ist dass so??
Als Switche habe ich mehrere Cisco SG200 bzw. SG300 und SF300 im Einsatz.
Eine weitere Frage ist noch, ob die Authentifizierung auch in VLAN's erfolgen kann, die keine Verbindung zum Server haben. Die Frage ist so gemeint, dass in dem Netzwerk insgesamt 5 VLAN's existieren und alle natürlich zwar über die Switche laufen aber nur auf zwei davon der Server Zugriff hat. Theoretisch könnte doch aber auch hier ein Client durch den Switch über den RADIUS authentifiziert werden - oder??
Hat jemand eventuell noch einige Hinweise was zu beachten ist oder ist das in 5 Minuten eingerichtet?
Vielen Dank für Eure Hilfe im Voraus und viele Grüße
Alex
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: 349369
Url: https://administrator.de/contentid/349369
Ausgedruckt am: 24.11.2024 um 02:11 Uhr
25 Kommentare
Neuester Kommentar
Hallo,
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/50s ...
https://sbkb.cisco.com/ciscosb/getarticle.aspx?docid=14b979f79d894bb3b66 ...
Gruß,
Peter
Zitat von @Alex29:
Zuerst die wichtigste Frage - kann ich, wenn ich die Authentifizierung am Server über den RemoteDesktop an einem Client einrichte, mich selbst aussperren?
Ja.Zuerst die wichtigste Frage - kann ich, wenn ich die Authentifizierung am Server über den RemoteDesktop an einem Client einrichte, mich selbst aussperren?
Oder kann das nicht passieren, da vorher noch am Switch Konfigurationen notwendig sind?
Dein Switch muss natürlich auch mitspielen bzw. wissen welche Ports nun 802.1x tun und welche nicht.Optimal wäre es, wenn man die Authetifizierung am Server einstellen kann und dann dem Switch sagen muss an welchen Ports authentifiziert werden soll - ist dass so??
Hast du denn schon irgendetwas über 802.1x gelesen, z.B. von Cisco oder so?https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/50s ...
https://sbkb.cisco.com/ciscosb/getarticle.aspx?docid=14b979f79d894bb3b66 ...
Eine weitere Frage ist noch, ob die Authentifizierung auch in VLAN's erfolgen kann, die keine Verbindung zum Server haben.
Wer soll denn dann die Authentifizierung vornehmen? Der Server der nicht erreicht werden kann?Hat jemand eventuell noch einige Hinweise was zu beachten ist oder ist das in 5 Minuten eingerichtet?
Ein CCNA wird es wohl in 5 Min. machen. Wie lange du brauchen wirst, wir wissen nicht was du beherscht oder kannst. Gruß,
Peter
Moin,
ich würde z.B. den Server mit dem RADIUS immer an einem Port laufen lassen der pauschal authentifiziert ist - ohne längere Anmeldung. Hintergrund: Nehmen wir an du machst die Anmeldung bei den Geräten per MAC-Adresse. Jetzt fliegt dir der Radius-Server auseinander (Katze hat reingepinkelt, Hund hat den als Knochen missbraucht oder nen Panzer ist drübergerollt). Du nimmst einen Ersatzserver - aber da ja alle Ports sich authentifizieren müssen kannst du den nicht anklemmen. Die können sich aber nicht Authentifizieren da der Server ja platt ist... Schade eigentlich...
Und ja - natürlich ist es eine theoretische Sicherheitslücke den Port offen zu lassen. Nur: Wer bei mir in den Serverraum (oder in meine Wohnung) kommt und somit Zugriff auf den Switch hat und dazu es noch schafft den Port zu finden, einen (gehackten) Server anzuklemmen der sonst alle Daten passend hat -> ja himmel noch mal, der hat es auch verdient das derjenige das Netz übernehmen kann... Den würde allerdings das bisschen Port-Security dann auch eh nicht lange abhalten. Von daher kann ich mit dieser Lücke ganz gut leben.
ich würde z.B. den Server mit dem RADIUS immer an einem Port laufen lassen der pauschal authentifiziert ist - ohne längere Anmeldung. Hintergrund: Nehmen wir an du machst die Anmeldung bei den Geräten per MAC-Adresse. Jetzt fliegt dir der Radius-Server auseinander (Katze hat reingepinkelt, Hund hat den als Knochen missbraucht oder nen Panzer ist drübergerollt). Du nimmst einen Ersatzserver - aber da ja alle Ports sich authentifizieren müssen kannst du den nicht anklemmen. Die können sich aber nicht Authentifizieren da der Server ja platt ist... Schade eigentlich...
Und ja - natürlich ist es eine theoretische Sicherheitslücke den Port offen zu lassen. Nur: Wer bei mir in den Serverraum (oder in meine Wohnung) kommt und somit Zugriff auf den Switch hat und dazu es noch schafft den Port zu finden, einen (gehackten) Server anzuklemmen der sonst alle Daten passend hat -> ja himmel noch mal, der hat es auch verdient das derjenige das Netz übernehmen kann... Den würde allerdings das bisschen Port-Security dann auch eh nicht lange abhalten. Von daher kann ich mit dieser Lücke ganz gut leben.
Hallo Peter,
vielen Dank für Deine schnelle Antwort
...das ist nicht so schön!! Wie kann ich das verhindern? Kann ich mich auch aussperren, wenn die Cisco Switche in der Standart-Konfig sind?
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/50s ...
https://sbkb.cisco.com/ciscosb/getarticle.aspx?docid=14b979f79d894bb3b66 ...
Die Artikel werde ich mir ansehen, ich habe aber schon viel dazu gelesen und die Authentifizierung über WLAN habe ich ja auch zum Laufen bekommen. Bisher hat mich nur die Gefahr des Aussperrens von der Konfig abgehalten und Dein eindeutiges "Ja" (sh. oben) macht mich nachdenklich.
Ich dachte der Client fragt beim Switch an. Der Switch kennt ja alle VLAN's und hat somit auch eine Verbindung zum Server. Der Switch müsste nur den Server über das "richtige" VLAN nach der Berechtigung fragen - oder?
Wenn ich die Gefahr des Aussperrens geklärt habe denke ich, bekomme ich es auch in 60 Min. hin
Viele Grüße
Alex
vielen Dank für Deine schnelle Antwort
Zuerst die wichtigste Frage - kann ich, wenn ich die Authentifizierung am Server über den RemoteDesktop an einem Client einrichte, mich selbst aussperren?
Ja....das ist nicht so schön!! Wie kann ich das verhindern? Kann ich mich auch aussperren, wenn die Cisco Switche in der Standart-Konfig sind?
Optimal wäre es, wenn man die Authetifizierung am Server einstellen kann und dann dem Switch sagen muss an welchen Ports authentifiziert werden soll - ist dass so??
Hast du denn schon irgendetwas über 802.1x gelesen, z.B. von Cisco oder so?https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/50s ...
https://sbkb.cisco.com/ciscosb/getarticle.aspx?docid=14b979f79d894bb3b66 ...
Die Artikel werde ich mir ansehen, ich habe aber schon viel dazu gelesen und die Authentifizierung über WLAN habe ich ja auch zum Laufen bekommen. Bisher hat mich nur die Gefahr des Aussperrens von der Konfig abgehalten und Dein eindeutiges "Ja" (sh. oben) macht mich nachdenklich.
Eine weitere Frage ist noch, ob die Authentifizierung auch in VLAN's erfolgen kann, die keine Verbindung zum Server haben.
Wer soll denn dann die Authentifizierung vornehmen? Der Server der nicht erreicht werden kann?Ich dachte der Client fragt beim Switch an. Der Switch kennt ja alle VLAN's und hat somit auch eine Verbindung zum Server. Der Switch müsste nur den Server über das "richtige" VLAN nach der Berechtigung fragen - oder?
Hat jemand eventuell noch einige Hinweise was zu beachten ist oder ist das in 5 Minuten eingerichtet?
Ein CCNA wird es wohl in 5 Min. machen. Wie lange du brauchen wirst, wir wissen nicht was du beherscht oder kannst. Wenn ich die Gefahr des Aussperrens geklärt habe denke ich, bekomme ich es auch in 60 Min. hin
Viele Grüße
Alex
Hallo,
LDAP = Kabel gebundene Klienten
Radius = Kabel lose Klienten
Gruß
Dobby
Nun würde ich gern einrichten, dass sich teilweise auch die drahtgebundenen Clients authentifizieren müssen.
LAP Rolle installieren und gut ist es!LDAP = Kabel gebundene Klienten
Radius = Kabel lose Klienten
Gruß
Dobby
Hallo maretz,
Danke für Deine Unterstützung.
Da bin ich Deiner Meinung würde ich auch nicht als Sicherhietslücke sehen. Mir geht es auch mehr um freizugängliche Netzwerkanschlüsse.
Kann ich mich also bei meiner Startkonfiguration nicht Aussperren, wenn ich den Server und den Client-Port, von dem ich aus im RemoteDesktop arbeite, hier auf "Force unauthorized" stelle?
Vielen Dank!!
Alex
Danke für Deine Unterstützung.
Da bin ich Deiner Meinung würde ich auch nicht als Sicherhietslücke sehen. Mir geht es auch mehr um freizugängliche Netzwerkanschlüsse.
Kann ich mich also bei meiner Startkonfiguration nicht Aussperren, wenn ich den Server und den Client-Port, von dem ich aus im RemoteDesktop arbeite, hier auf "Force unauthorized" stelle?
Vielen Dank!!
Alex
Hallo Dobby,
das verstehe ich noch nicht so richtig. "LDAP" ist doch die Anmeldung an der Windows-Domäne und schränkt nur den Zugriff auf den Server ein, nicht aber auf das Netzwerk. Soll das heißen, dass die Authentifizierung die ich vor hatte Sinnlos ist???
Grüß
Alex
das verstehe ich noch nicht so richtig. "LDAP" ist doch die Anmeldung an der Windows-Domäne und schränkt nur den Zugriff auf den Server ein, nicht aber auf das Netzwerk. Soll das heißen, dass die Authentifizierung die ich vor hatte Sinnlos ist???
Grüß
Alex
Hallo,
Jede Handlung birgt immer ein Risiko, nur manche Risiken sind leichter zu Ertragen
Gruß,
Peter
Zitat von @Alex29:
...das ist nicht so schön!! Wie kann ich das verhindern? Kann ich mich auch aussperren, wenn die Cisco Switche in der Standart-Konfig sind?
Je mehr du Konfigurierst je mehr Stellen gibt es wo du dich aussperren kannst. Vergiss dein Passwort und dann? Daher überleg deine Frage noch mal und meine passende Antwort dazu ...das ist nicht so schön!! Wie kann ich das verhindern? Kann ich mich auch aussperren, wenn die Cisco Switche in der Standart-Konfig sind?
Bisher hat mich nur die Gefahr des Aussperrens von der Konfig abgehalten und Dein eindeutiges "Ja" (sh. oben) macht mich nachdenklich.
Frag dich lieber ob du bei deinem Bruder eine Herz OP am offenen Herzen machen kannst ohne das er dir versehentlich wegstirbt, das wäre nämlich dann Blöd. Jede Handlung birgt immer ein Risiko, nur manche Risiken sind leichter zu Ertragen Wenn ich die Gefahr des Aussperrens geklärt habe denke ich, bekomme ich es auch in 60 Min. hin
Möchtest du Wetten? Gruß,
Peter
Hallo,
noch eine Unterschiedliche Instanz als die bereits vorhandene sollte man sich einmal den OpenLDAP Server anschauen!
Zusammen mit einem RaspBerry PI 3.0 und Tunrkey Linux hat man dann auch noch eine schicke Grafische Oberfläche
zum Konfigurieren! Tunrkey Linux & OpenLDAP
können und man dort mittels des Zertifikates schnell etwas unternehmen kann! Bei den Kabel gebundenen Geräten ist das
schon etwas anderes und wenn man den Radius Server zusammen mit Zertifikaten und einer Verschlüsselung benutzt,
"haut" einma das manchmal schon einen recht guten Schlag aufs LAN Kabel, will sagen, dass dann auch einmal der
gesamte Durchsatz im Netzwerk nach unten geht! Und um so etwas zu vermeiden teilt man sich meist solche
Aufgaben mittels Radius und LDAP Server.
gerne alles ganz klassisch denn der Radius Servre und die Verschlüsselung erzeugen je nach Anzahl der Klienten eine recht
hohe Netzwerklast! Und das macht der LDAP Server nicht! Somit kann man etwas vom Gesamtdurchsatz im Netzwerk retten
und muss nur eine weitere "Server Rolle" installieren. Man kann das wie schon weiter oben beschrieben mit einem extra LDAP
Server erledigen der dann nur die VLANs bedient die nicht mit dem Server VLAN verbunden sind oder gar darauf zugreifen!
Gruß
Dobby
das verstehe ich noch nicht so richtig. "LDAP" ist doch die Anmeldung an der Windows-Domäne und schränkt nur den Zugriff
auf den Server ein, nicht aber auf das Netzwerk.
Wenn man die LDAP Rolle auf dem Server benutzt ist es so und auch einfacher, wenn man aber eine weitere Instanz und dazuauf den Server ein, nicht aber auf das Netzwerk.
noch eine Unterschiedliche Instanz als die bereits vorhandene sollte man sich einmal den OpenLDAP Server anschauen!
Zusammen mit einem RaspBerry PI 3.0 und Tunrkey Linux hat man dann auch noch eine schicke Grafische Oberfläche
zum Konfigurieren! Tunrkey Linux & OpenLDAP
das verstehe ich noch nicht so richtig. "LDAP" ist doch die Anmeldung an der Windows-Domäne und schränkt nur den Zugriff
auf den Server ein, nicht aber auf das Netzwerk. Soll das heißen, dass die Authentifizierung die ich vor hatte Sinnlos ist???
Man trennt meist wegen der Kabel gebundenen und der Kabel losen Geräte weil die Kabel losen Geräte eben verloren gehenauf den Server ein, nicht aber auf das Netzwerk. Soll das heißen, dass die Authentifizierung die ich vor hatte Sinnlos ist???
können und man dort mittels des Zertifikates schnell etwas unternehmen kann! Bei den Kabel gebundenen Geräten ist das
schon etwas anderes und wenn man den Radius Server zusammen mit Zertifikaten und einer Verschlüsselung benutzt,
"haut" einma das manchmal schon einen recht guten Schlag aufs LAN Kabel, will sagen, dass dann auch einmal der
gesamte Durchsatz im Netzwerk nach unten geht! Und um so etwas zu vermeiden teilt man sich meist solche
Aufgaben mittels Radius und LDAP Server.
Soll das heißen, dass die Authentifizierung die ich vor hatte Sinnlos ist???
Nein auf keinen Fall denn das ist es nie wenn man mehr Sicherheit implementieren möchte, nur man teilt in der Regel auchgerne alles ganz klassisch denn der Radius Servre und die Verschlüsselung erzeugen je nach Anzahl der Klienten eine recht
hohe Netzwerklast! Und das macht der LDAP Server nicht! Somit kann man etwas vom Gesamtdurchsatz im Netzwerk retten
und muss nur eine weitere "Server Rolle" installieren. Man kann das wie schon weiter oben beschrieben mit einem extra LDAP
Server erledigen der dann nur die VLANs bedient die nicht mit dem Server VLAN verbunden sind oder gar darauf zugreifen!
Gruß
Dobby
Moin,
nein - Force Unauth meint was es sagt - der Port ist _immer_ gesperrt... Du möchtest Force Authorized haben
nein - Force Unauth meint was es sagt - der Port ist _immer_ gesperrt... Du möchtest Force Authorized haben
Die hiesigen Tutorials hast du gelesen ??
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
und auch:
Netzwerk Management Server mit Raspberry Pi
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
und auch:
Netzwerk Management Server mit Raspberry Pi
Hallo,
danke, für Eure Hinweise.
Ist es also richtig, wenn die Switche in der Standard-Konfig sind und alle Ports somit auf "Force authorized" stehen, kann ich auf dem Server beruhigt die Netzwerkrichtlinie erstellen ohne mich auszusperren. (Mir ist es wichtig, dass wenn ich an einem Client die Richtlinie über den RemoteDesktop auf dem Server erstelle, dass ich nicht plötzlich die Meldung bekomme, dass ich getrennt wurde und dann nicht mehr auf den Server komme.) Wenn dann die Netzwerkrichtlinie angelegt ist, "sage" ich dem Server noch welche Switche authentifizieren dürfen (anhand der IP-Adresse). Als letztes mache ich den Switchen den RADIUS-Server bekannt und stelle die Ports mit den Clients auf "Administrative Port Control: Auto".
Danke!!
Ich werde es testen.
Viele Grüße
Alex
danke, für Eure Hinweise.
Ist es also richtig, wenn die Switche in der Standard-Konfig sind und alle Ports somit auf "Force authorized" stehen, kann ich auf dem Server beruhigt die Netzwerkrichtlinie erstellen ohne mich auszusperren. (Mir ist es wichtig, dass wenn ich an einem Client die Richtlinie über den RemoteDesktop auf dem Server erstelle, dass ich nicht plötzlich die Meldung bekomme, dass ich getrennt wurde und dann nicht mehr auf den Server komme.) Wenn dann die Netzwerkrichtlinie angelegt ist, "sage" ich dem Server noch welche Switche authentifizieren dürfen (anhand der IP-Adresse). Als letztes mache ich den Switchen den RADIUS-Server bekannt und stelle die Ports mit den Clients auf "Administrative Port Control: Auto".
Danke!!
Ich werde es testen.
Viele Grüße
Alex
Moin,
nur am Rande: Du kannst dich auch so nicht so einfach aussperren bei Cisco... Einfacher Grund: Du stellst den Port auf "Auto" oder sogar auf "Force Unauth". Von mir aus nimm sogar _alle_ Ports und stell die auf Shut... Und? Die Konfig kannst du ja nicht mehr speichern da du dich gekillt hast bevor du nen "wr" gemacht hast oder auf Save running config klicken kannst. Also - reboot vom Switch und alles gut....
Bist du z.B. Remote drauf: Vorher nen Reload config in z.B 300 Sekunden einstellen. Dann die Konfig ändern. Hast du dich ausgesperrt -> schade, hol dir nen Kaffee. In 5 Min startet der Switch neu durch und alles wieder auf Anfang. Hast du dich nicht ausgesperrt und alles ist gut - speichern der Konfig (so du dir sicher bist) und den Reload abbrechen.
AUSNAHME: Du arbeitest auf einem Produktionssystem. Hier wäre das Vorgehen zwar gleich - aber wenn du auf einem Prod. System arbeitest und nicht vorher weisst was du tust dann würde ich eher ein Reload Brain empfehlen. Aber ich hoffe mal (und so wie es sich liest ist dem auch so) das es sich um eine Test-Umgebung handelt und da wäre ein Reload des Switches nicht weiter wild...
nur am Rande: Du kannst dich auch so nicht so einfach aussperren bei Cisco... Einfacher Grund: Du stellst den Port auf "Auto" oder sogar auf "Force Unauth". Von mir aus nimm sogar _alle_ Ports und stell die auf Shut... Und? Die Konfig kannst du ja nicht mehr speichern da du dich gekillt hast bevor du nen "wr" gemacht hast oder auf Save running config klicken kannst. Also - reboot vom Switch und alles gut....
Bist du z.B. Remote drauf: Vorher nen Reload config in z.B 300 Sekunden einstellen. Dann die Konfig ändern. Hast du dich ausgesperrt -> schade, hol dir nen Kaffee. In 5 Min startet der Switch neu durch und alles wieder auf Anfang. Hast du dich nicht ausgesperrt und alles ist gut - speichern der Konfig (so du dir sicher bist) und den Reload abbrechen.
AUSNAHME: Du arbeitest auf einem Produktionssystem. Hier wäre das Vorgehen zwar gleich - aber wenn du auf einem Prod. System arbeitest und nicht vorher weisst was du tust dann würde ich eher ein Reload Brain empfehlen. Aber ich hoffe mal (und so wie es sich liest ist dem auch so) das es sich um eine Test-Umgebung handelt und da wäre ein Reload des Switches nicht weiter wild...
Hallo maretz,
ich werde es am Wochenende testen.
Ja, es ist kein Produktivsystem sondern ein Heimnetzwerk. Von daher geht keine Herz-OP schief wenn das System nicht mehr läuft - blöd wäre es dennoch
Mein Fehler war, dass ich annahm in dem Moment wenn ich die Netzwerkrichtlinie auf dem Server konfiguriere diese sofort Anwendung findet und mich aussperrt. Deiner bzw. Euren Antworten entnehme ich aber, dass in diesem Moment "gar nichts" passiert sondern erst wenn ich die Ports am Switch konfiguriere. Somit kann ich Ports die eh nicht gepatcht sind "offen" lassen und habe immer Zugriff auf das System.
Danke auch für den Tip, dass man einstellen kann, dass der Switch selbständig die Konfig wieder verwirft, werden ich auch testen!!!
Viele Grüße
Alex
ich werde es am Wochenende testen.
Ja, es ist kein Produktivsystem sondern ein Heimnetzwerk. Von daher geht keine Herz-OP schief wenn das System nicht mehr läuft - blöd wäre es dennoch
Mein Fehler war, dass ich annahm in dem Moment wenn ich die Netzwerkrichtlinie auf dem Server konfiguriere diese sofort Anwendung findet und mich aussperrt. Deiner bzw. Euren Antworten entnehme ich aber, dass in diesem Moment "gar nichts" passiert sondern erst wenn ich die Ports am Switch konfiguriere. Somit kann ich Ports die eh nicht gepatcht sind "offen" lassen und habe immer Zugriff auf das System.
Danke auch für den Tip, dass man einstellen kann, dass der Switch selbständig die Konfig wieder verwirft, werden ich auch testen!!!
Viele Grüße
Alex
Moin,
ich glaub du hast das falsch verstanden: In dem Moment wo du Apply oder Return drückst (bei Cisco) wird der die Konfig übernehmen - d.h. da kannst du dich locker rausschiessen. ABER: Die Konfig ist dann nicht gespeichert - d.h. nach einem Switch-Reboot ist das wieder auf dem alten Wert.
Daher kann man ja den "Trick" machen das man vor einer solchen Änderung dem Switch sagt "Restart in 300 Sekunden" (oder 600, was immer dir beliebt). Mit dem drücken von Return läuft die Zeit - kein Problem... Jetzt konfigurierst du die Ports - und setzt leider auf allen Interfaces den Port auf "Shut". Du hast also grad den Switch gesagt das er keinen aktiven Port mehr hat. Schade eigentlich... Nehmen wir an dein Switch steht auf der ISS oder sonstwo - ist ja jetzt blöd hinzulaufen (oder der steht einfach nur 2m weiter und du bist zu faul aufzustehen, aber ich nehme ja nie Faulheit bei IT-Leuten an!). Also holst du dir einfach ne Tasse Kaffee, Tee, Cola,... Denn: Dein Switch hat immer noch das Kommando "Restart" drin. Also läuft der Timer ab, der switch startet neu und stellt die zuletzt gespeicherte Konfig wieder her (da waren die Ports ja dann nicht gesperrt). Dein Kaffee ist alle, die 300-600 Sekunden sind um und du fängst von vorne an -> fertig...
Du siehst, es ist sogar hilfreich für dich das mit dem Klick auf Apply / dem drücken von Return die Werte sofort aktiv werden. Es ist da - so du vorher das Reload aktiviert hast - gar kein Problem das du dich aussperrst. Andersrum wäre es schlimmer -> erst wenn du auf Save drückst passiert alles. Wenn das so wäre würdest du bei einem fehlerhaften Shut von allen Ports auf Safe drücken - tja, und dann bist du raus. Auch ein Reload hilft nix - jetzt müsstest du mit nem Konsolenkabel loslaufen...
ich glaub du hast das falsch verstanden: In dem Moment wo du Apply oder Return drückst (bei Cisco) wird der die Konfig übernehmen - d.h. da kannst du dich locker rausschiessen. ABER: Die Konfig ist dann nicht gespeichert - d.h. nach einem Switch-Reboot ist das wieder auf dem alten Wert.
Daher kann man ja den "Trick" machen das man vor einer solchen Änderung dem Switch sagt "Restart in 300 Sekunden" (oder 600, was immer dir beliebt). Mit dem drücken von Return läuft die Zeit - kein Problem... Jetzt konfigurierst du die Ports - und setzt leider auf allen Interfaces den Port auf "Shut". Du hast also grad den Switch gesagt das er keinen aktiven Port mehr hat. Schade eigentlich... Nehmen wir an dein Switch steht auf der ISS oder sonstwo - ist ja jetzt blöd hinzulaufen (oder der steht einfach nur 2m weiter und du bist zu faul aufzustehen, aber ich nehme ja nie Faulheit bei IT-Leuten an!). Also holst du dir einfach ne Tasse Kaffee, Tee, Cola,... Denn: Dein Switch hat immer noch das Kommando "Restart" drin. Also läuft der Timer ab, der switch startet neu und stellt die zuletzt gespeicherte Konfig wieder her (da waren die Ports ja dann nicht gesperrt). Dein Kaffee ist alle, die 300-600 Sekunden sind um und du fängst von vorne an -> fertig...
Du siehst, es ist sogar hilfreich für dich das mit dem Klick auf Apply / dem drücken von Return die Werte sofort aktiv werden. Es ist da - so du vorher das Reload aktiviert hast - gar kein Problem das du dich aussperrst. Andersrum wäre es schlimmer -> erst wenn du auf Save drückst passiert alles. Wenn das so wäre würdest du bei einem fehlerhaften Shut von allen Ports auf Safe drücken - tja, und dann bist du raus. Auch ein Reload hilft nix - jetzt müsstest du mit nem Konsolenkabel loslaufen...
Hey nochmal,
ich habe das schon richtig verstanden - mit dem Switch und dem Reboot bzw. dem automatischen Reboot.
Ursprünglich war ich jedoch in der Annahme das ich nicht mehr auf den Server!! komme, wenn ich die Richtlinie für Kabelgebunde Clients anlege (unabhängig vom Switch). Ich dachte der Server macht dann die eigene Netzwerkkarte "zu" wenn man nicht authentifiziert ist. Jetzt habe ich aber verstanden, dass mit der Netzwerkkarte (im Server) nichts passiert sondern nur der Switch den Zugang auf seine Ports regelt. Also komme ich ja immer auf den Server, da ich wenn nichts mehr geht (was ja aber nicht passieren kann) ich meinen Client direkt mit dem Server (cross-over) verbinden könnte.
Server und Switch sind in ähnlicher Entfernung wie die Kaffeemaschine!!
ich habe das schon richtig verstanden - mit dem Switch und dem Reboot bzw. dem automatischen Reboot.
Ursprünglich war ich jedoch in der Annahme das ich nicht mehr auf den Server!! komme, wenn ich die Richtlinie für Kabelgebunde Clients anlege (unabhängig vom Switch). Ich dachte der Server macht dann die eigene Netzwerkkarte "zu" wenn man nicht authentifiziert ist. Jetzt habe ich aber verstanden, dass mit der Netzwerkkarte (im Server) nichts passiert sondern nur der Switch den Zugang auf seine Ports regelt. Also komme ich ja immer auf den Server, da ich wenn nichts mehr geht (was ja aber nicht passieren kann) ich meinen Client direkt mit dem Server (cross-over) verbinden könnte.
Server und Switch sind in ähnlicher Entfernung wie die Kaffeemaschine!!
Hallo,
Natürlich kannst du dich auch aus einen Server aussperren und haben viele auch schon getan. Ist gar nicht Schwer und je nach was du angestellt hast ist auch Tastatur und Maus der Konsole tot. Beim Server wird meistens beim Klick auf OK die änderungen zum teil sofort wirksam und auch gespeichert, bei anderen Aktionen erst nach einem neuen Starten. Es kommt halt drauf an und das muss jeder Admin schon selbst abwägen, sonst finger weg. Jeder von uns hat schon mal da gestanden und sich überlegt "wenn ich jetzt ... wie komm ich dann wieder dran ... wie ist also mein Plan B?
Es ist immer abhängig davon was du wo und welche Geräte / Hertseller tun willst, z.B. Port Mirror eines Switch. Der eine Hersteller (Low Cost) macht einfach ein PortMirror ohne dich vom Netz zu trennen. Du nutzt das LAN über Port A, machst ein Mirror von Port X auf port A und gut ist. Ein Cisco SG-300 belehrt dich dann mit dein nicht mehr funktionierende Zugriff aud dein LAN das es so nun nicht geht. Der Portmirror tut zwar was er soll, aber du kommst halt nicht auf dein LAN und somit auf nicht mehr auf der Web GUI deines SG-300. Dummerweise sitzt du nun nicht mehr nur 3 meter weit weg, sondern 1800 Kilometer. Wenn dein Plan B nun Reisekosten und Flugtickets enthält ist ja wieder alles gut
Gruß,
Peter
Natürlich kannst du dich auch aus einen Server aussperren und haben viele auch schon getan. Ist gar nicht Schwer und je nach was du angestellt hast ist auch Tastatur und Maus der Konsole tot. Beim Server wird meistens beim Klick auf OK die änderungen zum teil sofort wirksam und auch gespeichert, bei anderen Aktionen erst nach einem neuen Starten. Es kommt halt drauf an und das muss jeder Admin schon selbst abwägen, sonst finger weg. Jeder von uns hat schon mal da gestanden und sich überlegt "wenn ich jetzt ... wie komm ich dann wieder dran ... wie ist also mein Plan B?
dass mit der Netzwerkkarte (im Server) nichts passiert sondern nur der Switch den Zugang auf seine Ports regelt.
Klar, wenn ich einen Switch konfiguriere ist es auch so.ich meinen Client direkt mit dem Server (cross-over) verbinden könnte.
Wie alt ist deine Hardware das du dort noch Crossover Kabel benötigst oder sind das dort noch NE2000 Kompatible oder 3C509B Netwerkkarten die von Auto MDI/MDI-X noch nichts kennen? Es ist immer abhängig davon was du wo und welche Geräte / Hertseller tun willst, z.B. Port Mirror eines Switch. Der eine Hersteller (Low Cost) macht einfach ein PortMirror ohne dich vom Netz zu trennen. Du nutzt das LAN über Port A, machst ein Mirror von Port X auf port A und gut ist. Ein Cisco SG-300 belehrt dich dann mit dein nicht mehr funktionierende Zugriff aud dein LAN das es so nun nicht geht. Der Portmirror tut zwar was er soll, aber du kommst halt nicht auf dein LAN und somit auf nicht mehr auf der Web GUI deines SG-300. Dummerweise sitzt du nun nicht mehr nur 3 meter weit weg, sondern 1800 Kilometer. Wenn dein Plan B nun Reisekosten und Flugtickets enthält ist ja wieder alles gut
Server und Switch sind in ähnlicher Entfernung wie die Kaffeemaschine!!
Dann einfach ausprobieren und notieren wann du dich ausgesperrt hast und wann nicht, hier hilft die Praxis mehr als die Theorie Gruß,
Peter
Hallo Peter,
natürlich ist mir bewusst, dass ich mich von dem Server aussperren kann, wenn ich zum Beispiel die Netzwerkkarte deaktiviere. Ich will jedoch nicht das Teil lahmlegen sondern wollte 802.1X-Authentifizierung implementieren, da ich auch Netzwerkdosen im Außenbereich habe und diese einfach etwas sicherer sein sollten (ja, ich kann auch die Patchkabel trennen).
Deshalb war mein Plan B mich vorher hier zu informieren, was ich bei der Implementierung beachten sollte. Die Authentifizierung meiner drahtlosen Clients habe ich auch hinbekommen.
Wie schon beschrieben, meine Befürchtung war, dass wenn ich auf dem Server die Richtlinie für drahtgebundene Clients erstelle sofort vom RemoteDesktop fliege, da die Netzwerkkarte des Servers eine Authentifizierung will, die sie in diesem Augenblick nicht hätte. Anhand Eurer Antworten glaube ich, dass diese Richtlinie aber mit der Netzwerkkarte des Servers nichts macht sondern nur auf die Ports der entsprechenden Switche wirkt.
Ich weis nicht genau, ob meine Netzwerkkarte Auto MDI/MDI-X unterstützt (bei den Switchen bin ich mir sicher). Ich habe das mit dem cross-over nur geschrieben, um Missverständnisse zu vermeiden. Deiner Antwort entnehme ich aber, dass Du mich zumindest in diesem Punkt verstanden hast!
Danke,
Alex
natürlich ist mir bewusst, dass ich mich von dem Server aussperren kann, wenn ich zum Beispiel die Netzwerkkarte deaktiviere. Ich will jedoch nicht das Teil lahmlegen sondern wollte 802.1X-Authentifizierung implementieren, da ich auch Netzwerkdosen im Außenbereich habe und diese einfach etwas sicherer sein sollten (ja, ich kann auch die Patchkabel trennen).
Deshalb war mein Plan B mich vorher hier zu informieren, was ich bei der Implementierung beachten sollte. Die Authentifizierung meiner drahtlosen Clients habe ich auch hinbekommen.
Wie schon beschrieben, meine Befürchtung war, dass wenn ich auf dem Server die Richtlinie für drahtgebundene Clients erstelle sofort vom RemoteDesktop fliege, da die Netzwerkkarte des Servers eine Authentifizierung will, die sie in diesem Augenblick nicht hätte. Anhand Eurer Antworten glaube ich, dass diese Richtlinie aber mit der Netzwerkkarte des Servers nichts macht sondern nur auf die Ports der entsprechenden Switche wirkt.
Ich weis nicht genau, ob meine Netzwerkkarte Auto MDI/MDI-X unterstützt (bei den Switchen bin ich mir sicher). Ich habe das mit dem cross-over nur geschrieben, um Missverständnisse zu vermeiden. Deiner Antwort entnehme ich aber, dass Du mich zumindest in diesem Punkt verstanden hast!
Danke,
Alex
dass diese Richtlinie aber mit der Netzwerkkarte des Servers nichts macht sondern nur auf die Ports der entsprechenden Switche wirkt.
Genau so ist es !! Siehe auch hier:https://de.wikipedia.org/wiki/IEEE_802.1X
Das grundlegende Prinzip ist doch immer klar: Der Switch ist der Authenticator, der macht alle Ports dicht sofern du keine Ausnahme konfiguriert hast und wartet das an einem Port ein Teilnehmer (Supplicant) ihn höflichst bittet ihn zu authorisieren.
Der teilnehmer ist der Bittsteller und dem Switch ist es herzlich egal ob das ein Server oder ein popeliger Winblows Rechner oder ein Raspberry Pi oder sonstwas ist.
Solange der Teilnehmer die 802.1x formatierte Bitte nicht an den Switch stellt sagt der "du kommst hier nicht rein !"
Mit Richtlinien oder anderem Windows Quatsch hat das erstmal rein gar nichts zu tun.
Klar kannst du dir den Ast absägen auf dem du selber sitzt. Wenn du nämlich ausnahmslos alle Ports des Switches für .1x aktivierst und für den Radius Serverport keine Ausnahme machst, dann sperrst du den Server selber aus...logisch und kommt man auch selber drauf.
Da nützt es auch nix den Server an der NIC .1x fähig zu machen, denn wen soll der Switch fragen wenn der Server ausgesperrt ist !
Der Server muss also von der 802.1x Authentisierung ausgenommen sein indem man es im Switchsetup an diesem Port deaktiviert.
...ja, wenn man erst mal verstanden hat wie es funktioniert ist es logisch!!
Damit klärt sich auch meine "weitere Frage" von ganz oben. Es kann also auch ein Client an einem Port authentifiziert werden, der in einem VALN "hängt" welches keine Verbindung zum RADIUS-Server hat, solange der Switch auf einem anderen Port den RADIUS-Server erreichen kann.
Mir ist nur noch nicht klar, woran der RADIUS-Server unterscheiden kann, ob es sich um eine Anfrage eines drahtgebundenen oder drahtlosen Clients handelt, bei W2k8 R1 wird hier unterschieden?
Danke!
Alex
Damit klärt sich auch meine "weitere Frage" von ganz oben. Es kann also auch ein Client an einem Port authentifiziert werden, der in einem VALN "hängt" welches keine Verbindung zum RADIUS-Server hat, solange der Switch auf einem anderen Port den RADIUS-Server erreichen kann.
Mir ist nur noch nicht klar, woran der RADIUS-Server unterscheiden kann, ob es sich um eine Anfrage eines drahtgebundenen oder drahtlosen Clients handelt, bei W2k8 R1 wird hier unterschieden?
Danke!
Alex
Hallo,
ich habe auch schon seit längerem mit 802.1X geliebäugelt - habe ebenfalls SG300er Switches.
Mich hat bisher davon abgehalten es zu implementieren, dass ich bei meiner beschaulichen Infrastruktur keine Ausfallsicherheit / Redundanz bereitstellen kann. Sicherlich hängt sowieso die halbe Infrastruktur schon am AD / DNS-Server aber ein bisschen was geht ja auch immer noch - selbst wenn der Server einmal ausfällt.
Vorteilhaft wäre es natürlich, auf andere weise - endlich würden alle mitbekommen, wenn der Server ein Problem hat und meine Arbeit bei der Wiederherstellung würde mehr geschätzt.
lcer
ich habe auch schon seit längerem mit 802.1X geliebäugelt - habe ebenfalls SG300er Switches.
Mich hat bisher davon abgehalten es zu implementieren, dass ich bei meiner beschaulichen Infrastruktur keine Ausfallsicherheit / Redundanz bereitstellen kann. Sicherlich hängt sowieso die halbe Infrastruktur schon am AD / DNS-Server aber ein bisschen was geht ja auch immer noch - selbst wenn der Server einmal ausfällt.
Vorteilhaft wäre es natürlich, auf andere weise - endlich würden alle mitbekommen, wenn der Server ein Problem hat und meine Arbeit bei der Wiederherstellung würde mehr geschätzt.
lcer
...ja, wenn man erst mal verstanden hat wie es funktioniert ist es logisch!!
Das sollte man ja wenn man ein Administrator Forum befragt, oder ?der in einem VALN "hängt" welches keine Verbindung zum RADIUS-Server hat, solange der Switch auf einem anderen Port den RADIUS-Server erreichen kann.
Genau so ist es !!Und...du kannst sogar, wenn du es denn willst, auch noch das VLAN dynamisch an diesem Port je nach Nutzer zuweisen per .1x !
ob es sich um eine Anfrage eines drahtgebundenen oder drahtlosen Clients handelt
Das kann und muss er ja auch gar nicht unterscheiden. Darum geht es bei .1x ja auch gar nicht. (Obwohl es in Kombination mit der MAC Adresse der NIC auch immer zu realisieren ist) Es geht darum ob das Endgerät oder der User berechtigt ist eine Netzwerk Resource zu nutzen. Nicht mehr und nicht weniger.Da ist es doch vollkommen egal ob WLAN, Kupfer oder feuchter Bindfaden.
ob es sich um eine Anfrage eines drahtgebundenen oder drahtlosen Clients handelt
Das kann und muss er ja auch gar nicht unterscheiden. Darum geht es bei .1x ja auch gar nicht. (Obwohl es in Kombination mit der MAC Adresse der NIC auch immer zu realisieren ist) Es geht darum ob das Endgerät oder der User berechtigt ist eine Netzwerk Resource zu nutzen. Nicht mehr und nicht weniger.Da ist es doch vollkommen egal ob WLAN, Kupfer oder feuchter Bindfaden.
Ich bin zwar auch der Meinung, dass die Unterscheidung nicht erforderlich ist. Bei der Konfig der Richtlinie im NPS wird jedoch nach "Drahtlos" und "Ethernet" unterschieden. Mir ist nur nicht klar woher "er" weis von was die Anfrage kommt. Vielleicht habe ich hier aber auch noch ein Verständnisproblem - ich werde es am Wochenende einfach testen.
Schönes WE und viele Grüße
Das ist Winblows bzw. NPS Kram und hat mit .1x per se rein gar nichts zu tun.
Verwende einen FreeRadius Radius Server dann wiesst du wovon man redet. Dort muss man so einen Unsinn nicht machen.
Nimm dir doch einfach mal einen Wireshark Sniffer und sieh dir die Radius Pakete an !!!
Dann wüsstest du das alles und müsstest nicht fragen
Verwende einen FreeRadius Radius Server dann wiesst du wovon man redet. Dort muss man so einen Unsinn nicht machen.
Mir ist nur nicht klar woher "er" weis von was die Anfrage kommt.
Es wird in der Anfrage immer der Switch Identifier mitgesendet und die Mac der NIC.Nimm dir doch einfach mal einen Wireshark Sniffer und sieh dir die Radius Pakete an !!!
Dann wüsstest du das alles und müsstest nicht fragen
Hallo,
ich habe die 802.1X-Authentifizierung hinbekommen - sogar ohne mich auszusperren!!
Allerdings habe ich jetzt weitere Probleme, da ich auch IP-Telefone und weitere Technik im Einsatz habe die nicht direkt die Authetifizierung unterstützen. Ich weis, dass ich somit die Mac-Bypass Authentifizierung einrichten kann. Allerdings bringt der Server hier noch die Fehlermeldung, dass der angegebene EAP nicht verarbeitet werden kann.
Hier werde ich mich noch weiter informieren und gegebenenfalls eine neue Frage eröffnen.
Vielen Dank für Eure Unterstützung bis hier!!
Alex
ich habe die 802.1X-Authentifizierung hinbekommen - sogar ohne mich auszusperren
!!Allerdings habe ich jetzt weitere Probleme, da ich auch IP-Telefone und weitere Technik im Einsatz habe die nicht direkt die Authetifizierung unterstützen. Ich weis, dass ich somit die Mac-Bypass Authentifizierung einrichten kann. Allerdings bringt der Server hier noch die Fehlermeldung, dass der angegebene EAP nicht verarbeitet werden kann.
Hier werde ich mich noch weiter informieren und gegebenenfalls eine neue Frage eröffnen.
Vielen Dank für Eure Unterstützung bis hier!!
Alex
Ich weis, dass ich somit die Mac-Bypass Authentifizierung einrichten kann
...und auch muss wenn du durchgängige Security erreichen willst. Wenn nicht musst du die Telefon Ports usw. dann von der .1x Auth ausnehmen, bist dann ber angreifbar weil das wieder offene Ports sind.dass der angegebene EAP nicht verarbeitet werden kann.
Normal ist das bei allen Radius Servern da als Username und Passwort die Mac Adresse angegeben wird.Allerdings muss man hier aufpassen WELCHERS Format der Hersteller da erfordert.
Einige machen es nach dem Muster 00-80-41-ae-fd-7e oder andere nach 00:80:41:ae:fd:7e oder wieder andere nach 008041aefd7e oder noch andere Formate.
Da hilft dann nur ein Blick ins Handbuch des jeweiligen Switches !!
