Meldungen vom AP an Radius Server EAP-PEAP

[Bernie137]

Hallo,

ich habe mal eine generelle Frage, wie sich Lancom APs gegenüber Radius Servern von Drittherstellern verhalten.

Wie darf ich mir den zeitlichen Ablauf bei Authentifizierung und Accounting Paketen vorstellen? Wir setzen ein EAP-PEAP mit Benutzername/Passwort aus dem AD.

Konkret haben wir in der Filale L-822acn/10.12.0147 und einen Radius in der Zentrale (Produkt TekRADIUS). Wie ist das für den Fall, dass der AP seine Meldungen in die Zentrale nicht (sofort) absetzen kann aufgrund Auslastung auf der WAN-Anbindung o.ä.? Cached der AP Anmeldungen?

Wir haben den Radius Server im Einsatz, um AD-Konten verwenden zu können und die WLAN-Anmeldung auf eine Session limitieren (kann MS-NPS nicht!) zu können. Aber es kommen hin und wieder Doppel-Anmeldungen zu Stande. Der Support des Radius Herstellers behauptet, die APs würden Anmelde Daten cachen, was ich mir nicht vorstellen kann. Aber ich wollte hier gerne einmal nachfragen.

Mit Traces komme ich nicht so recht weiter, da ich jeden AP rund 24h überwachen müsste, weil es dann irgendwann einmal vorkommt. Das führt eher zu Abstürzen, als dass es mir weiter hilft.

Gruß Bernie

[Bernie137]

Nachtrag:

Natürlich gibt es Meldungen und Log Einträge vom Radius Server. Hier zwei Beispiele, die Grund der Diskussion sind.

[alf29]

Moin,

also RADIUS-Requests sind erstmal UDP-Pakete. Der AP schickt sie los, und wenn er keine Antwort bekommt, zum Beispiel weil irgendwo auf dem Weg zum Server ein Engpaß besteht und der Request weggeworfen wurde, dann wird er ein paar Mal wiederholt. Wenn der AP nach der letzten Wiederholung immer noch keine Antwort bekommen hat, dann gilt das eben als ein "RADIUS-Server ist nicht da". Eine 802.1X-Anmeldung ist dann gescheitert, der Accounting-Request ist eben gescheitert.

Man könnte darüber diskutieren, nach Ablauf des Interim-Update-Intervalls einen Accounting-Start statt eines Interim-Update zu schicken, wenn der initiale Start nicht bestätigt wurde, vielleicht meint der Hersteller des RADIUS-Servers ja das mit "cachen". Ansonsten macht irgendwelches Caching für mich keinen Sinn, die in den Interim-Updates enthaltenen Accounting-Daten sind ja kumulativ, sie enthalten alle bisher in der Session verbrauchten Resourcen.

Viele Grüße

Alfred

P.S.: an dem zweiten Posting sehe ich keine Logs anhängen?

[Bernie137]

Hallo Alfred,

vielen Dank für Deine Antwort. Du bestätigst mir damit, wie ich es bisher auch verstanden habe, schon mal Danke!

Als Ergänzung vielleicht noch folgende Werte, welche in den APs eingestellt sind:
Accounting-Intervall: 300Sec
Reauthentication: ja
Re-Auth-Intervall: 300Sec

P.S.: an dem zweiten Posting sehe ich keine Logs anhängen?

Sorry, ja. Da bin ich bei meinem 2. Posting gestört worden, wollte es abbrechen und habe stattdessen auf Absenden gedrückt.

Nun liefere ich es nach:

Code: Alles auswählen

19.12.2017 10:31:33.800 - RadAcct req. from : 10.9.5.3:9203 [UDP]

Size              : 249 / 249
Identifier        : 184
Attributes        : 

 NAS-IP-Address = 10.9.5.3
 Calling-Station-Id = 48-27-EA-AF-13-96
 Called-Station-Id = 0A-A0-57-25-0C-EF:UMA
 NAS-Port-Id = 2
 Acct-Output-Octets = 744
 Acct-Input-Octets = 1746
 NAS-Port = 2
 Acct-Status-Type = Checkpoint
 Acct-Session-Time = 3
 Acct-Session-Id = 4827eaaf1396-1989357990
 NAS-Identifier = WLAN-KIRSCH2
 NAS-Port-Type = Wireless
 Framed-IP-Address = 192.168.183.69
 User-Name = Gleicher.Benutzer@DOMAIN.intern

19.12.2017 10:31:33.832 - RADIUS Accounting-Checkpoint packet from 10.9.5.3 for 'Gleicher.Benutzer@DOMAIN.intern', (Acct-Session-Id = 4827eaaf1396-1989357990 [184]) responded.

19.12.2017 10:31:45.466 - RadAcct req. from : 10.9.5.3:11686 [UDP]

Size              : 213 / 213
Identifier        : 185
Attributes        : 

 NAS-Port-Id = 4
 NAS-Port = 4
 Calling-Station-Id = 10-D3-8A-8F-BB-1D
 NAS-Port-Type = Wireless
 Acct-Status-Type = Start
 Acct-Session-Id = 10d38a8fbb1d-2004087913
 NAS-Identifier = WLAN-KIRSCH2
 User-Name = Gleicher.Benutzer@DOMAIN.intern
 Called-Station-Id = 0A-A0-57-25-0C-EF:UMA
 NAS-IP-Address = 10.9.5.3

19.12.2017 10:31:45.466 - Simultaneous session counter for user 'Gleicher.Benutzer@DOMAIN.intern' set to 2.

Man achte auf Calling-Station-ID und Acct-Session-Id, die sind nämlich unterschiedlich bei gleicher NAS-IP-Address! Für die MAC-Adresse 10-D3-8A-8F-BB-1D ist das die erste Meldung des APs um diese Uhrzeit. Davor wurde vom AP ein Accountig-Stop für diese MAC empfangen.

Das komplett von anderen Usern bereinigte Log File dieser fraglichen Uhrzeit hänge ich der Vollständigkeit halber mal mit ran. Ich bin halt ratlos. Das Problem trat an dem Tag um 10:31 Uhr und um 23:12 Uhr genau für diesen einen User auf.

Nachtrag: Unlogisch ist mir, dass zwischen 19.12.2017 10:31:33.832 Uhr und 19.12.2017 10:31:45.466 Uhr 12 Sekunden Funkstille zwischen beiden Einträgen war. Das ist auch in der Original Log Datei so. Ich kann mir das nur vorstellen mit Paket-Verlusten. Oder das Logging funktioniert nicht gescheit.

Gruß Bernie

[alf29]

Moin,

auf welche Weise Dein RADIUS.-Server Mehrfachlogins verhindern will, kann ich Dir nicht beantworten, das mußt Du mir sagen Aber vielleicht hatte der Client mit der MAC-Adresse 10-D3-8A-8F-BB-1D und der AP ein gecachtes Secret? Dann wird die 1X-Verhandlung übersprungen der RADIUS-Server erst gar nicht gefragt. Das würde sich auch in den Logs vom AP wiederfinden. Du sagst zwar, Du hast 300 Sekunden als Reauth-Periode eingetragen, was im Prinzip auch die Lifetime der Master-Secrets bestimmt, aber hast Du mal kontrolliert, ob die auch so beim AP unter Status/WLAN/PMK-Caching/Contents ankommt?

Viele Grüße

Alfred

[Bernie137]

Hi,

verhindern bzw. prüfen wird es der Radius anhand der 1X-Verhandlungen welche ein Accounting-Start zur Folge haben sollte. Mit dem Accounting-Start wird dann ein Wert Simultaneous-Use hochgezählt bzw. nach einem Accounting-Stop runter gezählt. So zumindest mein Verständnis der Sache.

aber hast Du mal kontrolliert, ob die auch so beim AP unter Status/WLAN/PMK-Caching/Contents ankommt

Nein, da hatte ich bis eben noch nie reingeschaut. Im Moment steht da für die aktiven User jeweils ein Wert kleiner 300 drin. Denke das ist OK.

Dann wird die 1X-Verhandlung übersprungen der RADIUS-Server erst gar nicht gefragt. Das würde sich auch in den Logs vom AP wiederfinden.

Wo würde ich das finden können bzw. nach was suche ich?

Gruß Bernie

[Bernie137]

Aber vielleicht hatte der Client mit der MAC-Adresse 10-D3-8A-8F-BB-1D ... ein gecachtes Secret?

Gute Frage. Daran habe ich noch gar nicht gedacht...ist Android.

Aber vielleicht hatte ... der AP ein gecachtes Secret?

genau das ist ja meine ursprüngliche Frage. Cached der AP irgendwas und könnte man dieses Verhalten beeinflussen?

[alf29]

genau das ist ja meine ursprüngliche Frage. Cached der AP irgendwas und könnte man dieses Verhalten beeinflussen?

Das ganze nennt sich PMK-Caching und ist eine Standard-Funktion von 802.11(i). Wenn ein Client zu einem AP zurückkehrt, kann er dem AP anbieten, das aus der letzten 1X-Verhandlung gewonnene Master Secret wiederzuverwenden. Wenn der AP das Secret auch noch hat, können beide die (teure, lange) 1X-Verhandlung überspringen - man kennt sich ja quasi schon.

Prinzipiell kannst Du PMK-Caching komplett in den Verschlüsselungseinstellungen abschalten, hat nur lange keiner mehr gemacht Ansonsten kann ein Secret auch herausaltern, das 1X-Reauthentisierungsintervall wird dabei als Lifetime angenommen.

Viele Grüße

Alfred

[Bernie137]

Hallo Alfred,

vielen Dank für Deine ausführlichen Erläuterungen. Das hilft mir erst einmal weiter, vielen Dank!

Ich habe es gefunden, wo ich PMK-Caching ausschalten könnte. Aber ich habe den Support des Radius damit konfrontiert und bin gespannt was sie dazu sagen. Denn die Funktion PMK-Cacheng könnte jeder andere AP der Welt auch haben. Und so richtig glaube ich auch noch gar nicht, dass es daran überhaupt liegen sollte. Die Log Files des Radius zeigen, dass der Radius nicht immer sauber arbeitet.

Gruß Bernie