WLC 4006 und Radius mit Windows 2008R2

[alf29]

Moin,

offensichtlich hat sich der WLC nicht als RADIUS-Server an die APs übermittelt. RADIUS-Server auf dem WLC ist wirklich an? Ich habe hier bei mir Authentisierung und Accounting an (Ports 1812 & 1813), in den RADIUS-Profilen bei mir stehen nur Nullen.

Auf dem WLC unter "WLAN-Controller" -> Profile gibt es ja das Radius-Profil. Dort ist nichts eingetragen [also dort gibts nur die 2 Default-Einträge "Default" und "Default_Backup" und beim log. WLAN steht auch Default drin - muss hier vielleicht doch noch was eingestellt werden?

steht bei mir hier genauso...einziger Unterschied ist, daß ich die 1x-Requests direkt von RADIUS-Server des WLC behandeln lasse, anstatt sie weiterzuleiten, aber das spielt dafür, daß die APs den WLC als RADIUS-Server zugewiesen bekommen, erstmal keine Rolle.

Kann man das auch so machen, wenn der WLC noch ein Public Spot Netz hat? Habe ne ähnliche Konstellation und würde eben gerne noch ein IAS WLAN dazulegen. Einzelne APs mit IAS hab ich schon am Laufen.

Weiterleiten oder Forwarden wird vom RADIUS-Server im LCOS nur anhand von Realms festgemacht. Realms werden üblicherweise mit einem @ an den Benutzernamen angehängt, also etwas in der Art 'user@telekom' und wenn man der Forwarding-Tabelle einen Eintrag 'TELEKOM' macht, dann werden RADIUS-Anfragen mit Benutzernamen, die desen Realm haben, entsprechen weitergeleitet.

Ein nicht allzu bekanntes Feature des RADIUS-Servers im LCOS ist aber, daß er einen *vorangestellten* Domänen-Präfix ebenfalls wie einen Realm behandelt. Wenn die Benutzer also beim 802.1X mit Benutzerkennungen der Form 'domaim\user' ankommen, dann wird der RADIUS-Server im LCOS in der Forwarding-Tabelle nach einem Eintrag für 'DOMAIN' suchen. Findet er den, wird dorthin weitergeleitet. Falls Deine 1x-Logins also bereits einen Domänen-Präfix haben, ist das vergleichsweise einfach.

Gruß Alfred

[jbaecker]

Es läuft nun!

Allerdings habe ich ein Problem: Wir haben netzwerkgespeicherte Nutzerprofile. Damit das auch im WLAN funktioniert, müssten wir die Computer- oder Benutzerauthentifizierung nutzen.
Laut Lancom-Support muss jedoch der "Leere Realm" auch leer bleiben, damit Public Spot funktioniert - das funktioniert auch per Radius und mit "leerem" Realm.

Das Problem dabei: Wenn der PC sich authentifiziert (nach dem booten, vor dem Userlogin), sendet er leider keinen Realm (obwohl er auch in der Domäne ist).
Mit dem Domänenbenutzer klappt das wunderbar!

Hat hier noch jemand eine Idee?

Gruß
jbaecker

PS: Danke bis hierher schonmal!

[Bernie137]

Moin,

@Alfred: Wenn die Domain z.B. Telekom heißt und es ein REALM Eintrag existiert, ist es dann nicht wurscht, ob Telekom\user oder user@telekom als Realm ankommt? Die Frage ist nur, wie es bei Computer Konten und eben nicht Benutzerkonten funktioniert. Also vor dem Userlogin, so wie es jbaecker beschreibt. Das wäre bei uns beabsichtigt.

@jbaecker: Schön das es funktioniert nun. Auch wenn ich nicht direkt helfen konnte.

Laut Lancom-Support muss jedoch der "Leere Realm" auch leer bleiben, damit Public Spot funktioniert - das funktioniert auch per Radius und mit "leerem" Realm.

Das Problem dabei: Wenn der PC sich authentifiziert (nach dem booten, vor dem Userlogin), sendet er leider keinen Realm (obwohl er auch in der Domäne ist).

Ja das sehe ich auch als Problem, auch wenn ich im Moment nicht sagen kann wie es bei uns ist. Was ich nicht erreichen möchte, dass plötzlich alle Public Spot Geschichten (Hotelgäste) beim IAS ankommen und dadurch Public Spot nicht mehr funktioniert. Beim IAS sollen nur bestimmte Notebooks angemeldet werden, die unserer eigenen Domain.

Leider bin ich diese Woche nicht vor Ort und kann es mir nicht genauer anschauen. Vielleicht geht es dann doch besser, wenn jeder AP einzeln sich mit IAS unterhält? Ab LCOS 8.8 kann man ja Radius Einstellungen über den WLC mit ausrollen habe ich gesehen, würde aber lieber auf die 8.82 warten wollen.

Gruß Heiko

[jbaecker]

So - ich hab es nun wegen dem Problem mit dem Public Spot doch anders gelöst - die APs befinden sich nun im selben Netz wie der WLC - vorher waren sie im anderen Netz und konnten warum auch immer nicht direkt mit dem Radius reden. Ich hatte es bis dahin nicht hinbekommen, ein Netz auf 2 Schnittstellen, aber nur auf einer Schnittstelle ist der DHCP aktiv (eben für die APs) - das klappt nun auch.

Nun läuft fast alles wie gewünscht - nur das Public Spot muss noch eingerichtet werden. Aber das bekomme ich sicher hin Und wenn nicht, wende ich mich vertrauensvoll ans Forum.

An alle Beteiligten: Danke für Anregungen, Ideen, Anleitungen! Es hat mir alles irgendwie geholfen

Gruß
jbaecker

[alf29]

Moin,

@Alfred: Wenn die Domain z.B. Telekom heißt und es ein REALM Eintrag existiert, ist es dann nicht wurscht, ob Telekom\user oder user@telekom als Realm ankommt?

Das ist dem RADIUS-Server im LCOS egal, der wird 'telekom' in beiden Fällen als Realm betrachten.

Die Frage ist nur, wie es bei Computer Konten und eben nicht Benutzerkonten funktioniert. Also vor dem Userlogin, so wie es jbaecker beschreibt. Das wäre bei uns beabsichtigt.

Ganz ehrlich: von diesem 'Windows-Gedöns' mit Computer- versus Benutzerauthentisierung habe ich Null Ahnung, ich habe mich damit noch nie beschäftigen müssen. Der RADIUS-Server sieht im Request erstmal nur ein Attribut 'User-Name', ob der jetzt im Zusammenhang mit dem einen oder anderen gekommen ist, weiß er nicht.

Gruß Alfred

[Bernie137]

Hi,

Das ist dem RADIUS-Server im LCOS egal, der wird 'telekom' in beiden Fällen als Realm betrachten.

Dann habe ich es auch richtig verstanden. Danke.

Ganz ehrlich: von diesem 'Windows-Gedöns' mit Computer- versus Benutzerauthentisierung habe ich Null Ahnung, ich habe mich damit noch nie beschäftigen müssen.

Interesse das einmal zu tun? Ich schaue mir das nächste Woche mal eingehender an. Der Trace interessiert mich und den kann ich doch auch erst einmal auf einem autarken AP (L-54g) generieren? Also was sendet ein Windows Client, der zur Domain gehört und sich per 802.1x als Computer authentifizieren soll.

Oder gibt es hier jemanden, der es schon am Laufen hat: WLC mit Public Spot + internem Radius und 2. logischen WLAN bei dem sich nur der WLC gegenüber externen Radius (IAS) ausweist für Windows Domain Clients?

Gruß Heiko

[alf29]

Moin,

Interesse das einmal zu tun? Ich schaue mir das nächste Woche mal eingehender an. Der Trace interessiert mich und den kann ich doch auch erst einmal auf einem autarken AP (L-54g) generieren? Also was sendet ein Windows Client, der zur Domain gehört und sich per 802.1x als Computer authentifizieren soll.

Was die Identity angeht, vermute ich mal, wird das etwas in der Form 'domain\hostname' sein, für das Forwarding zum IAS macht das also keinen Unterschied zu einer Benutzer-Authentisierung. Was ich mich immer gefragt habe, ist wo die Credentials für das PEAP/MSCAPv2 herkommen, also was bei einer Maschinen-Authentisierung als 'Paßwort' benutzt wird - für Fälle, wo Kunden eben keinen IAS dastehen haben, sondern das 802.1X auf dem RADIUS-Server im LCOS benutzen...

Gruß Alfred

[jbaecker]

Hi,

nein, er kommt mit gar keinem Realm bei der Maschinenauthentifzierung. Und das ist das Problem, weil genau so funktioniert das Public Spot - mit einem leeren Realm, wo dann das Lancomgerät als Radiusserver fungiert. [was so betrachtet das Public Spot auch logisch erklärt - also die Funktionsweise dessen ].

Gruß
jbaecker

[Bernie137]

Hi,

Was ich mich immer gefragt habe, ist wo die Credentials für das PEAP/MSCAPv2 herkommen, also was bei einer Maschinen-Authentisierung als 'Paßwort' benutzt wird - für Fälle, wo Kunden eben keinen IAS dastehen haben, sondern das 802.1X auf dem RADIUS-Server im LCOS benutzen...

Zertifikate der eigenen Windows Domain! Der interne LC Radius ist wohl gegen einen MS Radius in einem Domain Netzwerk kein Ersatz hinsichtlich der Skalierbarkeit. Es kommen da eine Reihe von Vorteilen und Administrationsvereinfachungen zum tragen, wofür aber nicht allein der MS Radius verantwortlich ist. Übrigens haben Domain Computerkonten auch Passworte, wird dafür aber nicht genutzt.

In kleineren Umgebungen ohne Domain bzw. MS Radius kann man über LC Radius gehen mit User/Passwort. Ist nur eine Frage der Sicherheit dann, speziell in Firmen. @Home habe ich es aber mit PEAP/MSCHAPv2 gegen LC Radius als Spielwiese.

nein, er kommt mit gar keinem Realm bei der Maschinenauthentifzierung. Und das ist das Problem

Ja mir war auch so, als ich letztens damit rumgespielt habe. Aber ganz genau weis ich es eben nicht mehr. Darum schaue ich nächste Woche noch mal nach. Ihr habt es also nicht am Laufen über einen WLC?

Gruß Heiko

[jbaecker]

Nein, ich habs nun direkt über die APs.

[alf29]

Moin,

Zertifikate der eigenen Windows Domain!

Das wäre dann aber kein PEAP mehr, denn bei PEAP authentisiert der Client sich gegenüber dem Server mit Benutzernamen und Paßwort in der Phase 2 (also dem MSCHAPv2) und nicht in der Phase 1 mit einem Zertifikat - danach fragt der LCOS-RADIUS-Server bei PEAP gar nicht, nur wenn als EAP-Methode TLS verwendet wurde. Mag sein, daß ein IAS bei PEAP in der Phase 1 auch immer nach einem Zertifikat fragt und in der Phase 2 anders agiert, wenn er eines bekommen hat, so etwas unterstützt der RADIUS-Server im LCOS aber nicht (und ich müßte dafür auch erstmal eine Doku haben, wie Microsoft sich das genau vorstellt...).

Der interne LC Radius ist wohl gegen einen MS Radius in einem Domain Netzwerk kein Ersatz hinsichtlich der Skalierbarkeit.

Mag sein, für viele der 'Microsoft-Spezialitäten' fehlt auch das Active-Directory, was bei dem IAS hintendran hängt bzw. jemand müßte für das LCOS einen AD- bzw. LDAP-Client schreiben, der dann gestatten würde das abzufragen. War mal im Gespräch, ist aber wieder in der Versenkung verschwunden...

Gruß Alfred

[Bernie137]

Hi,

nein, es ist ganz richtig EAP TLS. Ich habe nun mehrere Traces gemacht. In Kurzform nur der wichtigste Ausschnitt, generiert auf einem WLC4006, LCOS 8.62.0029RU1, neuer_AP war ein L-54g:

Code: Alles auswählen

[RADIUS-Server] 2013/07/15 14:42:03,169  Devicetime: 2013/07/15 14:42:03,544
Received RADIUS authentication request 241 from client xxx.xxx.14.66:3072[HAUSNETZ]:
-->known attributes of request:
   User-Name           : host/N-TECRAA11.xxxx.local
   Service-Type        : Framed
   NAS-Identifier      : neuer_AP
   NAS-IP-Address      : xxx.xxx.14.66
   NAS-Port            : 1 
   NAS-Port-Id         : 1
   NAS-Port-Type       : Wireless - IEEE 802.11
   State:
   0000: ba c6 11 e0 5d 63 08 f0 2e b1 84 78 17 58 c2 3c  ....]c.....x.X.<
   Called-Station-Id   : 06-0F-A3-83-2E-BE:WLAN
   Calling-Station-Id  : 00-26-B6-DC-4D-BA
   Message-Authenticator:
   0000: de 3b 7e 80 07 72 4e c0 ab 28 b4 ed 84 d3 81 25  .;~..rN..(.....%
   Connect-Info        : CONNECT 54 Mbps 802.11g
   Framed-MTU          : 1500 bytes
   EAP-Message:
   (6 bytes)
   -->EAP Header
   EAP Packet Code     : Response
   EAP Packet Id       : 2
   EAP Packet Len      : 6
   EAP Packet Type     : NAK
   Desired EAP Type(s) : TLS
-->user name contains no realm, using empty realm
-->realm of user is ''
-->authenticating locally
-->did not find user 'host/N-TECRAA11.xxxx.local' in database(s)
-->authenticating via EAP
-->queueing request for later response

Das bedeutet nun, das der Realm nicht wie vermutet bei Windows Computer Konten leer ist, sondern in der Form "host/N-TECRAA11.xxxx.local" daher kommt. Nun funktioniert aber ein angelegter Realm "HOST" nicht, da danach ein Slash "/" und nicht Backslash "\" kommt , bezogen auf ...

Ein nicht allzu bekanntes Feature des RADIUS-Servers im LCOS ist aber, daß er einen *vorangestellten* Domänen-Präfix ebenfalls wie einen Realm behandelt. Wenn die Benutzer also beim 802.1X mit Benutzerkennungen der Form 'domaim\user' ankommen, dann wird der RADIUS-Server im LCOS in der Forwarding-Tabelle nach einem Eintrag für 'DOMAIN' suchen.

Gruß Heiko

[alf29]

Moin,

Das bedeutet nun, das der Realm nicht wie vermutet bei Windows Computer Konten leer ist, sondern in der Form "host/N-TECRAA11.xxxx.local" daher kommt. Nun funktioniert aber ein angelegter Realm "HOST" nicht, da danach ein Slash "/" und nicht Backslash "\" kommt , bezogen auf ...

Ich denke auch nicht, daß Microsoft in diesem Fall den Slash als Trennzeichen für einen Domänenprefix gedacht hat, sondern als Hinweis auf eine andere Form der Authentifizierung (eben Host vs. Benutzer). Von daher wäre es wohl auch nicht gut, den Slash wie einen Backslash zu behandeln. Mittelfristig wird man wohl nicht herumkommen, die Forwarding-Regeln etwas flexibler zu gestalten und nicht nur auf einen Realm zu beziehen, sondern z.B. auch auf die Called-Station-ID...

Gruß Alfred

[Bernie137]

Moin,

Mittelfristig wird man wohl nicht herumkommen, die Forwarding-Regeln etwas flexibler zu gestalten und nicht nur auf einen Realm zu beziehen, sondern z.B. auch auf die Called-Station-ID...

oder einfach für bestimmte SSIDs. Innerhalb einer SSID braucht man wohl kaum unterschiedliche Authentifizierungen.

Mag sein, für viele der 'Microsoft-Spezialitäten' fehlt auch das Active-Directory, was bei dem IAS hintendran hängt bzw. jemand müßte für das LCOS einen AD- bzw. LDAP-Client schreiben, der dann gestatten würde das abzufragen. War mal im Gespräch, ist aber wieder in der Versenkung verschwunden...

Das ist nicht schlimm und vielleicht auch überhaupt nicht notwendig. Jeder Kunde, der ein Active Directory hat, kann ohne Zusatzkosten einen IAS (MS Radius) installieren. Und die Kunden, die kein Active Directory haben, brauchen auch keinen LCOS AD Client.

Gruß Heiko

[alf29]

Moin,

oder einfach für bestimmte SSIDs. Innerhalb einer SSID braucht man wohl kaum unterschiedliche Authentifizierungen.

Das meinte ich mit der Called-Station-Id, aus der Sicht eines RADIUS-Servers, der Requests für 802.1X verarbeitet, steht die SSID in dem Attribut 'Called-Station-Id':

Called-Station-Id : 06-0F-A3-83-2E-BE:WLAN

Das müßte so eine Regel in der Form 'wenn Called-Station-Id = *:WLAN, dann forwarde an...' sein.

Gruß Alfred