Radius Server und Service-Type

[alexw]

Hallo,

da ich den Lancom Radius Server nicht nur für WLAN Authentifizierungen benutzen möchte, sondern auch gleich für den ganzen Rest, der Radius kann, ist die Service-Type Auswahl leider etwas zu wenig
Ich gehe mal von aus, dass in der GUI "Dienst-Typ" eine Auswahl des Service-Type darstellt. Soweit sehr gut.
Da einige Switches sich ebenfalls über einen Radius Server authentifizierne können, wäre zumindest noch das "Administrative" Attribut hilfreich, siehe http://tools.ietf.org/search/rfc2865#section-5.6.
Im trace wird das übertragene Service-Type Feld nicht angezeigt, ist das so gewollt?

Ok, wäre das eine option die restlichen Attribute auch noch zu unterstützen?
Danke

[alf29]

Moin,

zur 9.00 werden mehr Service-Typen drin sein:

Code: Alles auswählen

Possible Entries for columns in Users:
[1][User-Name]          : 48 chars from: #ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'()*+-,/:;<=>?[\]^_.0123456789abcdefghijklmnopqrstuvwxyz `
[5][Calling-Station-Id-Mask]    : 64 chars from: #ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'()*+-,/:;<=>?[\]^_.0123456789abcdefghijklmnopqrstuvwxyz `
[6][Called-Station-Id-Mask]   : 64 chars from: #ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'()*+-,/:;<=>?[\]^_.0123456789abcdefghijklmnopqrstuvwxyz `
[20][Active]            : No (0), Yes (1)
[17][Case-Sensitive]    : Yes (0), No (1)
[2][Password]           : 32 chars from: #ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'()*+-,/:;<=>?[\]^_.0123456789abcdefghijklmnopqrstuvwxyz `
[9][Multiple-Login]     : Yes (0), No (1)
[19][Max-Concurrent-Logins]   : 10 chars from: 1234567890
[13][Expiry-Type]       : Bitmask: absolute (1), relative (2), none (0)
[10][Abs.-Expiry]       : 21 chars from:  0123456789/:.Pp
[14][Rel.-Expiry]       : 10 chars from: 1234567890
[11][Time-Budget]       : 10 chars from: 1234567890
[12][Volume-Budget]     : 10 chars from: 1234567890
[15][Comment]           : 251 chars from: #ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'()*+-,/:;<=>?[\]^_.0123456789abcdefghijklmnopqrstuvwxyz `
[16][Service-Type]      : Any (0), Login (1), Framed (2), Callback-Login (3), Callback-Framed (4), Outbound (5), Administrative (6), NAS-Prompt (7), Auth.-Only (8), Callback-NAS-Prompt (9), Call-Check (10), Callback-Administrative (11), Voice (12), Fax (13), Modem-Relay (14), Authorize-Only (17), Framed-Management (18)
[3][Limit-Auth-Methods] : Bitmask: PAP (1), CHAP (2), MSCHAP (4), MSCHAPv2 (8), EAP (16), All (32768)
[4][VLAN-Id]            : 4 chars from: 1234567890
[7][Tx-Limit]           : 10 chars from: 1234567890
[8][Rx-Limit]           : 10 chars from: 1234567890
[18][WPA-Passphrase]    : 63 chars from: #ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'()*+-,/:;<=>?[\]^_.0123456789abcdefghijklmnopqrstuvwxyz `
[21][Shell-Priv.-Level] : 10 chars from: 1234567890

Im trace wird das übertragene Service-Type Feld nicht angezeigt, ist das so gewollt?

Welchen Trace meinst Du? Im RADIUS Server Trace ist das drin:

Code: Alles auswählen

[RADIUS-Server] 2014/02/13 15:07:47,171
Received RADIUS authentication request 146 from client 192.168.11.117:3072[INTRANET]:
-->known attributes of request:
   User-Name           : bat54
   Service-Type        : Framed
   NAS-Identifier      : l320-aarnold-alt
   NAS-IP-Address      : 192.168.11.117
   NAS-Port            : 1 
   NAS-Port-Id         : 1
   NAS-Port-Type       : Wireless - IEEE 802.11
   Called-Station-Id   : 02-A0-57-17-10-14:AA_MSDU
   Calling-Station-Id  : 00-02-6F-BE-F1-1E
   Message-Authenticator:
   0000: 3e 66 0b de cd 27 fb 0e df 18 10 7e 6f e9 1c 3f  >f...'.....~o..?
   Connect-Info        : CONNECT 54 Mbps 802.11a
   Framed-MTU          : 1500 bytes
   EAP-Message:
   (10 bytes)
   -->EAP Header
   EAP Packet Code     : Response
   EAP Packet Id       : 1
   EAP Packet Len      : 10
   EAP Packet Type     : Identity
   Identity String     : bat54
-->user name contains no realm, using empty realm
-->realm of user is ''
-->authenticating locally
-->found user 'bat54' in database(s)
-->authenticating via EAP
-->queueing request for later response

Gruß Alfred

[alexw]

Nabend,

zur 9.00 werden mehr Service-Typen drin sein:

Cool, genial! Aber bis zur Release dauerts noch eine ganze Ecke

Welchen Trace meinst Du? Im RADIUS Server Trace ist das drin:

Hm, bei dem, glaube MD5, Request von einem Net*ear Switch sieht das ganze so aus:

Code: Alles auswählen

[RADIUS-Server] 2014/02/13 15:45:28,768
Received RADIUS authentication request 1 from client 192.168.10.253:1024[10_MANAGEMENT]:
-->known attributes of request:
   User-Name           : admin
   User-Password       : xxxxx
   NAS-Identifier      : xx-xx-xx-xx-xx-xx
   Message-Authenticator:
   0000: a3 65 8b 14 7b 32 e3 5e 61 8c 9f 2e f3 7d e9 d3  .e..{2.^a....}..
-->user name contains no realm, using empty realm
-->realm of user is ''
-->authenticating locally
-->found user 'admin' in database(s)
-->authenticating via PAP
-->response type is Accept, response attributes:
-->sending response

[alf29]

Moin,

das heißt dann aber schlicht, daß der Netgear-Switch kein solches Attribut in den Request reinschreibt. Muß er auch nicht, lt. RFC darf ein RADIUS-Request zwischen Null und einem Attribut dieses Typs enthalten.

Gruß Alfred

[alexw]

Moin,

würde das dann aber bedeuten, wenn der Client dieses Attribut nicht in den Request schreibt, dass es auch nicht vom Lancom Radius Server als Antwort übermittelt wird?

Alex

[alf29]

Moin,

der RADIUS-Server im LCOS schreibt nie ein Service-Type-Attribut in seine Antworten, egal ob eines im Request drin war oder nicht.

Gruß Alfred

[SunSeb]

Hallo,

würde etwas dagegen sprechen das Service-Type-Attribut (falls konfiguriert) in die Anwort einzufügen?

Manche Geräte werten dieses aus. Handbuchauszug Patton Smartnode Configuration Guide:

Attributes in the RADIUS accept message
After the user and his credentials are approved by the authentication procedure on the RADIUS server, the
SmartNode expects a RADIUS accept message with the following attributes:

Attribute number: 6
Attribute Type: Service-Type
Description: If the value is set to 'administrative', the user has administrator rights
on the SmartNode, otherwise operator rights

Schönen Tag,
Sebastian

[alf29]

Moin,

dagegen spricht erstmal, daß der Service-Typ in der RADIUS-Benutzertabelle nicht soherum definiert ist - er ist soherum gedacht, daß der NAS einen Request mit einem Service-Typ stellt (in dem Sinne 'Benutzer x will sich für Dienst y anmelden') und der RADIUS-Server prüft dann, ob der Benutzer für diesen Dienst freigeschaltet ist. Wenn der Service-Typ in der Benutzertabelle zum Request paßt oder auf 'beliebig' steht, dann gibt es ein Accept, ansonsten ein Reject.

Manche Geräte werten dieses aus. Handbuchauszug Patton Smartnode Configuration Guide:

Das finde ich ehrlich gesagt ein bißchen gewagt, an ein Attribut, daß zur Auswahl eines bestimmten Diensttyps gedacht ist (als z.B. Dial-In oder Netzwerkeinwahl), verschiedene Zugriffsrechte zu hängen. Zum einen ist das Attribut in seinen Auswahlmöglichkeiten dazu viel zu eingeschränkt, und zum anderen gibt es andere Attribute, die explizit dafür gedacht sind. Wie z.B. das nicht nur im Cisco-Umfeld weit verbreitete Shell-Privilege-Attribut, das der RADIUS-Server im LCOS ab 9.00 pro User anbieten wird.

Ich könnte mir bestenfalls vorstellen unter den Bedingungen

(1) Der NAS liefert in seinem Request keinen Service-Typ
(2) In der Benutzertabelle ist ein Service-Typ ungleich any definiert

in den Accept den Service-Typ reinzuschreiben. Wäre aber auch schon ziemlich erklärungsbedürftig...

Gruß Alfred

[SunSeb]

Hallo,

vielen Dank für die ausführliche und informative Erläuterung. Nun erscheint der Zusammenhang in neuem Licht und bin ganz deiner Meinung...

Gruß und Danke,
Sebastian

[alexw]

Hi,

überzeugt mich ebenfalls, aber die Vermutung liegt nahe, dass diese billig Hersteller es sich so einfach wie möglich machen.
Trotzdem habe ich eine Anfrage zumindest an einen dieser auffälligen Hersteller gesandt.

[Henri]

Hallo Alfred,

ich habe hier das gleiche Problem mit HP Procurves.
Vielleicht könnt Ihr ja ein paar Attribute vom Nutzer einstellbar zurückgeben, wenn dieser das möchte sonst wird die Radius Infrastruktur schnell sehr unübersichtlich.

To supply a privilege level via RADIUS, specify the “Service-Type” attribute in the user’s credentials.
•
Service-Type = 6 allows manager-level access
•
Service-Type = 7 allows operator-level access
•
A user with Service-Type not equal to 6 or 7 is denied access
•
A user with no Service-Type attribute supplied is denied access when privilege mode is enabled

[alf29]

Moin,

ich habe das jetzt noch mal nachgelesen und die meinen das wirklich ernst? Ein Attribut, was per RFC eine völlig andere Bedeutung hat, wird hier 'mißbraucht', um Benutzerprivilegien in Richtung Switch zu kommunizieren?

Die Lösung, die ich weiter oben vorgeschlagen habe, würde so weit wie ich es verstehe hier nicht greifen, da ein HP-Switch in den Access-Request bereits einen Service-Type reinschreibt (nämlich Administrative-User oder NAS-Prompt-User) und das Feld in der Benutzertabelle wird bereits für das Matching gegen den Typ im Request 'verbraucht'.

Was ich mir allenfalls vorstellen könnte, wäre für das Feld mit den Shell-Priviledge-Level Sonderwerte zu definieren, die dazu führen, daß der Wert nicht als Cisco-AVP rausgeschrieben wird. Cisco benutzt keine Werte >15, man könnte etwas basteln a la 'Shell-Priv.-Level = 1006 -> Service-Type 6'. Was natürlich nur funktioniert, wenn der Kunde keine gemischte Infrastruktur hat...

Gruß Alfred