2
Diverse Fragen zu NAC, IAS und HP ProCurve Switchen
Hallo zusammen,
ich arbeite mich gerade in das Thema NAC ein. Hierzu habe ich eine Laborumgebung aufgebaut.
Ziel ist Folgendes: Stöpselt sich ein User am Switch an und wird die Authentifizerung (EAPoL/RADIUS) erfolgreich durchgeführt,
kommt er in das VLAN 1. Schlägt die Authentifizerung fehl (oder handelt es sich um einen Gast), wird das VLAN 5 am Switch-Port
auf untagged gesetzt.
Aktuell sieht das Konstrukt so aus:
- 1 x Domain Controller mit IAS (Win 2k3 R2)
- 1 x HP ProCurve Switch (2610)
- 2 Clients (Windows Notebook, das EAP-Authentifizerung unterstütz und einen Client, der das nicht kann)
Switchkonfiguration:
aaa authentication port-access eap-radius authorized
radius-server host IPADRESSEMEINESSERVERS key GEHEIM
aaa port-access authenticator 24
aaa port-access authenticator 24 auth-vid 1
aaa port-access authenticator 24 unauth-vid 5
aaa port-access authenticator active
Funktioniert soweit alles wunderbar.
Jetzt habe ich dazu aber noch Fragen:
Ich würde gerne die VLAN's dynamisch in Abhängigkeit der Authentifizerung zuweisen. Hierzu habe ich auf dem IAS in der Richtline
folgendes hinzugefügt:
Leider zeigt diese Einstellung überhaupt keine Wirkung. Bei erfolgreicher Authentifizerung lande ich immer wieder im VLAN 1.
Ansonsten im VLAN 5. Laut HP müsste aber die VLAN-Konfiguration am Switch durch die RADIUS-Vorgabe überschrieben werden.
Oder habe ich da was falsch verstanden?
Außerdem sollen zukünftig auch Geräte (VoIP-Telefone, Drucker, usw.) betrieben werden, die kein EAP sprechen können.
HP bietet als Alternative die MAC-Authentifizierung an. Würde soweit auch funktionieren. Leider muss ich dann in der AD Benutzer anlegen,
bei denen der Name und das Passwort der MAC-Adresse entspricht. Halte ich für nicht sicher. Außerdem verbietet das die Kennwortrichtline
(Domain-Policy). Was habe ich für Alternativen?
Wie geht ihr mit VoIP VLAN's um? Also an Ports, an denen im Prinzip zwei Clients hängen. Das VoIP-Telefon sollte einen getaggten Ethernetframe
erhalten. Der andere Client ist im ungetaggtem VLAN. Entweder im Gastnetzwerk oder eben im "normalen" LAN:
Danke schon mal!
Grüße
ich arbeite mich gerade in das Thema NAC ein. Hierzu habe ich eine Laborumgebung aufgebaut.
Ziel ist Folgendes: Stöpselt sich ein User am Switch an und wird die Authentifizerung (EAPoL/RADIUS) erfolgreich durchgeführt,
kommt er in das VLAN 1. Schlägt die Authentifizerung fehl (oder handelt es sich um einen Gast), wird das VLAN 5 am Switch-Port
auf untagged gesetzt.
Aktuell sieht das Konstrukt so aus:
- 1 x Domain Controller mit IAS (Win 2k3 R2)
- 1 x HP ProCurve Switch (2610)
- 2 Clients (Windows Notebook, das EAP-Authentifizerung unterstütz und einen Client, der das nicht kann)
Switchkonfiguration:
aaa authentication port-access eap-radius authorized
radius-server host IPADRESSEMEINESSERVERS key GEHEIM
aaa port-access authenticator 24
aaa port-access authenticator 24 auth-vid 1
aaa port-access authenticator 24 unauth-vid 5
aaa port-access authenticator active
Funktioniert soweit alles wunderbar.
Jetzt habe ich dazu aber noch Fragen:
Ich würde gerne die VLAN's dynamisch in Abhängigkeit der Authentifizerung zuweisen. Hierzu habe ich auf dem IAS in der Richtline
folgendes hinzugefügt:
Leider zeigt diese Einstellung überhaupt keine Wirkung. Bei erfolgreicher Authentifizerung lande ich immer wieder im VLAN 1.
Ansonsten im VLAN 5. Laut HP müsste aber die VLAN-Konfiguration am Switch durch die RADIUS-Vorgabe überschrieben werden.
Oder habe ich da was falsch verstanden?
Außerdem sollen zukünftig auch Geräte (VoIP-Telefone, Drucker, usw.) betrieben werden, die kein EAP sprechen können.
HP bietet als Alternative die MAC-Authentifizierung an. Würde soweit auch funktionieren. Leider muss ich dann in der AD Benutzer anlegen,
bei denen der Name und das Passwort der MAC-Adresse entspricht. Halte ich für nicht sicher. Außerdem verbietet das die Kennwortrichtline
(Domain-Policy). Was habe ich für Alternativen?
Wie geht ihr mit VoIP VLAN's um? Also an Ports, an denen im Prinzip zwei Clients hängen. Das VoIP-Telefon sollte einen getaggten Ethernetframe
erhalten. Der andere Client ist im ungetaggtem VLAN. Entweder im Gastnetzwerk oder eben im "normalen" LAN:
Danke schon mal!
Grüße
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 142337
Url: https://administrator.de/contentid/142337
Printed on: April 18, 2024 at 23:04 o'clock
2 Comments
Latest comment
So sollte diese Einstellung sein:
Damit klappt es dann auch auf Anhieb.
Was meinst du mit VoIP VLANs. Was du beschreibst ist der allgemein übliche Umgang bzw. Konfigurations eines VoIP VLAN Ports... wo ist da jetzt die Frage ??
Es ist klar das der Voice Traffic immer getaggt sein muss, denn jeder Voice Hersteller aktiviert eine Layer 2 Priorisierung mit 802.1p. Da aber ein 802.1p Header immer Teil einen 802.1q Headers ist sind also Voice Pakete immer getagged um ein Layer 2 QoS mit den Voice daten im netz zu machen !
Ein am internen Telefon Switch angeschlossener PC ist untagged...logisch.
Der 802.1q Standard schreibt vor das das Default VLAN immer untagged an einem tagged Port übertragen wird. Jedem normalen Switch (wenn nicht gerade Billigheimer ala NetGear oder D-Link usw. sind) kannst du in der Konfig sagen in welches VLAN er den untagged Traffic an diesem Port forwarden soll.
Logischerweise geht das auch mit einer Port Authentifizierung via 802.1x wie du es machst. Und das sogar getrennt für das Telefon und den PC.
Beim Telefon dann Mac Adressbasierend wenn es keinen 802.1x Client haben sollte !
Noch einfacher ist es aber mit automatischen Voice VLANs zu arbeiten die dann per LLDP med Protokoll im Netz gesetzt werden.
So einfach ist das !!
Damit klappt es dann auch auf Anhieb.
Was meinst du mit VoIP VLANs. Was du beschreibst ist der allgemein übliche Umgang bzw. Konfigurations eines VoIP VLAN Ports... wo ist da jetzt die Frage ??
Es ist klar das der Voice Traffic immer getaggt sein muss, denn jeder Voice Hersteller aktiviert eine Layer 2 Priorisierung mit 802.1p. Da aber ein 802.1p Header immer Teil einen 802.1q Headers ist sind also Voice Pakete immer getagged um ein Layer 2 QoS mit den Voice daten im netz zu machen !
Ein am internen Telefon Switch angeschlossener PC ist untagged...logisch.
Der 802.1q Standard schreibt vor das das Default VLAN immer untagged an einem tagged Port übertragen wird. Jedem normalen Switch (wenn nicht gerade Billigheimer ala NetGear oder D-Link usw. sind) kannst du in der Konfig sagen in welches VLAN er den untagged Traffic an diesem Port forwarden soll.
Logischerweise geht das auch mit einer Port Authentifizierung via 802.1x wie du es machst. Und das sogar getrennt für das Telefon und den PC.
Beim Telefon dann Mac Adressbasierend wenn es keinen 802.1x Client haben sollte !
Noch einfacher ist es aber mit automatischen Voice VLANs zu arbeiten die dann per LLDP med Protokoll im Netz gesetzt werden.
So einfach ist das !!
Servus!
Danke erstmal. Hab den Eintrag "Framed-Protocol" hinzugefügt. Leider hilft das auch nicht. Ich lande mit dem authentifizierten Client immer im "auth-vid". Also im VLAN 1.
Wie kann ich die MAC Adressbasierte Authentifizierung realisieren? Bisher kenne ich nur den Weg, dass man in der AD einen Benutzer anlegen muss, der als ID und Kennwort jeweils
die MAC-Adresse eingetragen hat. Halte ich wie gesagt für nicht sicher, da diese User automatische in der AD-Gruppe "Authentifizierte Benutzer" sind. Außerdem können MAC Adressen
ja relativ leicht herausgefunden und/oder geändert werden.
Grüße
Danke erstmal. Hab den Eintrag "Framed-Protocol" hinzugefügt. Leider hilft das auch nicht. Ich lande mit dem authentifizierten Client immer im "auth-vid". Also im VLAN 1.
Wie kann ich die MAC Adressbasierte Authentifizierung realisieren? Bisher kenne ich nur den Weg, dass man in der AD einen Benutzer anlegen muss, der als ID und Kennwort jeweils
die MAC-Adresse eingetragen hat. Halte ich wie gesagt für nicht sicher, da diese User automatische in der AD-Gruppe "Authentifizierte Benutzer" sind. Außerdem können MAC Adressen
ja relativ leicht herausgefunden und/oder geändert werden.
Grüße
