7
Allgemeine Frage zu 802.1x mit Zertifikaten
Hallo,
ich habe mir hier in einer Testumgebung mit einem DC, NPS-Server und einer 2-stufigen CA aufgebaut. Dazu ein ProCurve-Switch. Zur Konfig:
Auf dem NPS-Server ist eine Netzwerkrichtlinie erstellt worden. Unter Authentifizierungsmetode wurde Smartcard oder Zertifikat ausgewählt. Der NPS-Server besitzt ein gültiges Zertifikat.
Der Client besitzt auch ein gültiges Computerzertifkat. Sobald ich den Netzwerkstecker einstecke, dauert es immer ziemlich genau 20s bis der Client den Status "Authentifiziert" hat.
Ich wollte eigentlich nur wissen, ob diese Zeit normal ist oder ob der Vorgang doch zu lange dauert. Ich persönlich meine, dass das schneller gehen müsste. Beim Neustart sieht man das nicht sofort, da bei beim Anmelden das Netzwerk schon vorhanden ist.
Gibt zu diesem Zeitraum Erfahrungswerte?
ich habe mir hier in einer Testumgebung mit einem DC, NPS-Server und einer 2-stufigen CA aufgebaut. Dazu ein ProCurve-Switch. Zur Konfig:
Auf dem NPS-Server ist eine Netzwerkrichtlinie erstellt worden. Unter Authentifizierungsmetode wurde Smartcard oder Zertifikat ausgewählt. Der NPS-Server besitzt ein gültiges Zertifikat.
Der Client besitzt auch ein gültiges Computerzertifkat. Sobald ich den Netzwerkstecker einstecke, dauert es immer ziemlich genau 20s bis der Client den Status "Authentifiziert" hat.
Ich wollte eigentlich nur wissen, ob diese Zeit normal ist oder ob der Vorgang doch zu lange dauert. Ich persönlich meine, dass das schneller gehen müsste. Beim Neustart sieht man das nicht sofort, da bei beim Anmelden das Netzwerk schon vorhanden ist.
Gibt zu diesem Zeitraum Erfahrungswerte?
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: 400613
Url: https://administrator.de/contentid/400613
Printed on: April 16, 2024 at 11:04 o'clock
7 Comments
Latest comment
Nein, diese Zeit ist nicht normal. Das sollte eigentlich nach max. 5 Sek erledigt sein.
Man kann hier leider nur raten da deine Beschreibung sehr mager ist.
Vermutlich hast du Spanning Tree aktiv im RSTP Mode und die Client Ports nicht in den Edge Mode konfiguriert.
Da müssen die dann durch den gesamten RSTP Learning und Forwarding Prozess und das dauert bekanntlich so zw. 20 und 30 Sekunden.
Vermutlich also eine Fehlkonfiguration der HP Gruselgurke im RSTP bzw. Spanning Tree. Denn sogar HP kann damit umgehen...
Guckst du auch hier:
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
Man kann hier leider nur raten da deine Beschreibung sehr mager ist.
Vermutlich hast du Spanning Tree aktiv im RSTP Mode und die Client Ports nicht in den Edge Mode konfiguriert.
Da müssen die dann durch den gesamten RSTP Learning und Forwarding Prozess und das dauert bekanntlich so zw. 20 und 30 Sekunden.
Vermutlich also eine Fehlkonfiguration der HP Gruselgurke im RSTP bzw. Spanning Tree. Denn sogar HP kann damit umgehen...
Guckst du auch hier:
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
Nein, diese Zeit ist nicht normal. Das sollte eigentlich nach max. 5 Sek erledigt sein.
Ok, das ist ja schon mal ne Aussage.
Man kann hier leider nur raten da deine Beschreibung sehr mager ist.
Richtig, aber da kann ich ja noch "nachliefern". Ich wollte erstmal nur wissen, ob diese Zeit normal ist.Ich werde morgen auf der Gruselgurke nachsehen, ob dort STP und sich der Port für Edge einstellen lässt.
Ich habe noch dunkel in Erinnerung, dass bei den ProCurve STP immer defaultmäßig an ist. Mit Edge bin ich jetzt überfragt. Aber das habe ich morgen schnell raus. Also bei den HP-Geräten mit Comware ist ist defenitiv möglich. Aber in diesem Fall ist das ein ProCurve 2610.
Ich habe jetzt auf dem Switch nachgesehen, ob STP aktiviert war. Nein, ist es nicht.
Was ich jetzt nochmal ausprobiert habe:
Am Client habe ich die 802.1x Authentifizierung wieder deaktiviert und anschließend das Gerät mit einem Port verbunden, der keine Authentifizierung benötigt.
Nach ca. 8s war der Rechner mit dem LAN verbunden.
Anschließend habe ich dem Computer eine feste IP-Adresse zugewiesen. Danach Stecker raus und wieder rein. Hier war der Computer nach ca. 3s am Netz.
Hier scheint es mit der langen Verzögerung wohl doch mit dem Zertifkat zusammenzuhängen. Nur ich komme ich nicht drauf, was das sein könnte.
Beim Überprüfen in der MMC Unternehmens-PKI ist mir aufgefallen, dass es bei der Bereitstellung der Sperrlisten unter http Probleme gab. Die habe ich beseitigt und noch einmal probiert. Hier brachte es aber keine Verbesserung.
Was ich jetzt nochmal ausprobiert habe:
Am Client habe ich die 802.1x Authentifizierung wieder deaktiviert und anschließend das Gerät mit einem Port verbunden, der keine Authentifizierung benötigt.
Nach ca. 8s war der Rechner mit dem LAN verbunden.
Anschließend habe ich dem Computer eine feste IP-Adresse zugewiesen. Danach Stecker raus und wieder rein. Hier war der Computer nach ca. 3s am Netz.
Hier scheint es mit der langen Verzögerung wohl doch mit dem Zertifkat zusammenzuhängen. Nur ich komme ich nicht drauf, was das sein könnte.
Beim Überprüfen in der MMC Unternehmens-PKI ist mir aufgefallen, dass es bei der Bereitstellung der Sperrlisten unter http Probleme gab. Die habe ich beseitigt und noch einmal probiert. Hier brachte es aber keine Verbesserung.
So, jetzt habe ich eine Lösung gefunden:
Ein Connect dauert jetzt statt der 18s ungefähr 2s.
Mit dem Wireshark hatte ich auf dem Client gesehen, dass ein Request Identity vom Swich sofort ankam. Der Client hat auch sofort mit einem Response Identity geantwortet. Zur gleichen Zeit am Radius-Server kam nichts an.
Dann war nach 18s das Frage-Antwortspiel am Client erneut zu sehen. Jetzt ging aber die Anfrage vom Switch zum Radius raus. Danach war der Rechner auch authentifiziert.
Abhilfe schaffte die Verkürzung der Zeit vom Parameter tx-period. Hier die Zeile für den ProCurve:
aaa port-access authenticator 1-24 tx-period 2
Ob das jetzt so klug war und diesen Wert so zu verkürzen, weiß ich jetzt nicht.
Ein Connect dauert jetzt statt der 18s ungefähr 2s.
Mit dem Wireshark hatte ich auf dem Client gesehen, dass ein Request Identity vom Swich sofort ankam. Der Client hat auch sofort mit einem Response Identity geantwortet. Zur gleichen Zeit am Radius-Server kam nichts an.
Dann war nach 18s das Frage-Antwortspiel am Client erneut zu sehen. Jetzt ging aber die Anfrage vom Switch zum Radius raus. Danach war der Rechner auch authentifiziert.
Abhilfe schaffte die Verkürzung der Zeit vom Parameter tx-period. Hier die Zeile für den ProCurve:
aaa port-access authenticator 1-24 tx-period 2
Ob das jetzt so klug war und diesen Wert so zu verkürzen, weiß ich jetzt nicht.
Normal ist es jedenfalls nicht, denn man muss solche Parameter in der Regel nicht ändern ! Aber was ist schon normal an solchen HP Gruselgurken...??
Wenns jetzt rennt bitte dann
How can I mark a post as solved?
nicht vergessen.
Wenns jetzt rennt bitte dann
How can I mark a post as solved?
nicht vergessen.
Hallo,
Von hier: http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/WB/15-18/ ... Also war da schon einer dran wenn dort 18 drin stand.
Gruß,
Peter
Von hier: http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/WB/15-18/ ...
[tx-period <0-65535>]
Sets the period the port waits to retransmit the next EAPOL PDU during an authentication session. (Default: 30 seconds)Gruß,
Peter
Also war da schon einer dran wenn dort 18 drin stand.
Nee, glaube ich nicht. Ich habe den Switch vorher resetet. Ich gehe jetzt einfach mal davon aus, dass dieser alle Werkseinstelllungen übernommen hatte.
Beim Stöbern sind mir diese beiden Seiten ins Auge gefallen:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB15062& ...
Hier wird auch der Wert "2" verwendet.
Und hier geht man etwas mehr auf diese Problematik ein: Das ist zwar für Cisco, sollte aber für HP genauso gelten.
https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/Trus ...