Catalyst 2960 ignores Radius attributes to set VLAN

[raarons]

Hi all

I am trying to deploy 802.1X for wired authentication and VLAN assignment into an existing Cisco network.  I am able to get the Radius server to rturn the correct attributes to the switch according to the presented credentials, for instance

tunnel-type=13

tunnel-medium-type=6

tunnel-private-group-id=100

which should theoretically set the port access vlan ID to 100.  However, the switch is resolutely ignoring this.

Here's an edited debug from a so-called successful authentication:

Aug 22 14:30:29.484: RADIUS: Received from id 1645/195 10.240.5.20:1812, Access-Accept, len 456

Aug 22 14:30:29.484: RADIUS:  authenticator BE C7 70 72 11 20 FA 46 - 14 94 03 19 93 D9 9C E9

Aug 22 14:30:29.484: RADIUS:  Tunnel-Type         [64]  6   00:VLAN                   [13]

Aug 22 14:30:29.484: RADIUS:  Tunnel-Medium-Type  [65]  6   00:ALL_802                [6]

Aug 22 14:30:29.484: RADIUS:  Tunnel-Private-Group[81]  7   00:"100 "

Aug 22 14:30:29.484: RADIUS:  Class               [25]  255

...

Aug 22 14:30:29.518: RADIUS(00000030): Received from id 1645/195

Aug 22 14:30:29.518: RADIUS/DECODE: EAP-Message fragments, 4, total 4 bytes

Aug 22 14:30:29.518: %DOT1X-5-SUCCESS: Authentication successful for client (0022.6422.2222) on Interface Fa0/1 AuditSessionID 0AF00420000000200F0D1412

Aug 22 14:30:29.518: %AUTHMGR-7-RESULT: Authentication result 'success' from 'dot1x' for client (0022.6422.2222) on Interface Fa0/1 AuditSessionID 0AF00420000000200F0D1412

Aug 22 14:30:30.533: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up

Aug 22 14:30:30.793: %AUTHMGR-5-SUCCESS: Authorization succeeded for client (0022.6422.2222) on Interface Fa0/1 AuditSessionID 0AF00420000000200F0D1412

Aug 22 14:30:32.219: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up

But the port remains resolutely in the native vlan.  NB The VLAN is valid for the switch.

Some Cisco docs say the tunnel-private-group-id should be the name of the vlan, not the VID, so I have tried this, but the result is the same.

I have also tried sending the attributes as Cisco-AVPairs, with the same results.

What have I missed?  The switch is running 12.2(55)SE, and I have also tried with 12.2(58)SE2, with the same results.  Relevant config is:

aaa group server radius RAD-SERV

server 10.240.5.20 auth-port 1812 acct-port 1813

!

aaa authentication dot1x default group RAD-SERV

!

vlan 9

name NATIVE-DISCARD

!

vlan 100

name STAFF

!

interface FastEthernet0/1

switchport access vlan 9

switchport mode access

switchport voice vlan 800

authentication order dot1x mab webauth

authentication priority dot1x mab webauth

authentication port-control auto

mab

dot1x pae authenticator

dot1x timeout supp-timeout 5

spanning-tree portfast

Any advice gratefully received.

[Julio Garcia · Accepted solution]

Hi Raarons,

Not too familiar with dynamic vlan assignment, but i think perhaps you need something like ..

aaa authorization network default group RAD-SERV

to get this to work.

[raarons]

Hi Rob

Got it in one!  Silly me!

Many thanks

Rob A

[Peter Paluch · Accepted solution]

Hello,

Rob is absolutely correct here, you also need to activate authorization as Rob suggested to actually process the specific RADIUS attributes.

The style of configuring the attributes is OK, i.e. they have worked for me this way:

u10   Cleartext-Password:=u10

        Tunnel-Type=13,

        Tunnel-Medium-Type=6,

        Tunnel-Private-Group-ID=10

In addition, are you using FreeRADIUS as your RADIUS server? If so and if you are using tunneled authentication methods (PEAP, TTLS, etc.) you need to configure the following in the /etc/freeradius/eap.conf in sections for ttls and peap modules:

use_tunneled_reply = yes

This command forces RADIUS to send the attributes based on the username in the inner authentication mechanism, because with PEAP or TTLS, the outside tunnel protection is usually done with anonymous identity, or the inner authentication mechanism does not include the attributes in the final Access-Accept RADIUS message. The debugs provided by the Catalyst are actually quite misleading here: they display the attributes as sent at the beginning of the authentication process because the FreeRADIUS likes to slap the attributes onto the Access-Challenge messages (where they are largely useless) but when the final Access-Accept message is sent, the FreeRADIUS honors the setting of this command. If it is set to "no", the attributes assigned to the particular user will not be sent, hence the problems.

When modifying the FreeRADIUS configuration, these commands will be probably already present, just set to "no".

Best regards,

Peter

[raarons]

Hi Peter

I'm not using FreeRadius, but Juniper UAC, however I had previously set up a FreeRadius server to sanity-check my UAC settings, and discovered the same problems once I'd overcome the use_tunneled_reply hurdle..

Many thanks for the help to all.

Regards

Rob A