Getting VLANs in the RADIUS access-requests without IBNS 2 or MAB

[Nadav]

Hi all,

Using IOS-XE you can send vlan information in the Tunnel-Private-Group-ID attribute, but that means having to convert configuration to IBNS 2. Apparently this can also be done when using MAB authentication.

My question is this:  Can it be done without IBNS 2 and without MAB?  (Purely for 802.1x)

[Damien Miller]

Dynamic vlan does work with traditional 802.1x (ibns 1.0) or C3PL ibns 2.0 configs. I have used dvlan with ibns 1.0 for a number of years.

This older guide covers it with the traditional 802.1x configs.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_8021x/configuration/xe-3se/3650/sec-user-8021x-xe-3se-3650-book/sec-ieee-8021x-vlan-assign.pdf

Specifically this section and it is handled the same way with ibns 1.0 or 2.0. The challenge is always the endpoint when you change a vlan if the client has an IP already. The endpoint doesn't know the vlan changed, it doesn't know it needs to renew it's IP.

"You must assign the following vendor-specific tunnel attributes in the RADIUS server database. The RADIUS server must return these attributes to the device:

IEEE 802.1X VLAN Assignment
Specifying an Authorized VLAN in the RADIUS Server Database
• [64] Tunnel-Type = VLAN
• [65] Tunnel-Medium-Type = 802
• [81] Tunnel-Private-Group-ID = VLAN name or VLAN ID
Attribute [64] must contain the value “VLAN” (type 13). Attribute [65] must contain the value “802” (type 6). Attribute [81] specifies the VLAN name or VLAN ID assigned to the IEEE 802.1X-authenticated user"

[Nadav]

Thanks for the response,

I'm not looking to use dynamic vlans. I'm interested in the VLAN of the access port for the ISE RADIUS policy. I can't get the attribute to be sent so that I can decide whether to permit or deny access on that static VLAN assignment.

[Arne Bier]

@Nadav - your question is rather confusing - sorry,  don't really know what you're after. IOS-XE does NOT mandate that you use IBNS at all. You can stay old school if you wish. In my experience you can use the age old commands on newer IOS-XE switches and all works well. Cisco would like us to move to IBNS (and using 3CPL) but it's not mandatory.

If you simply return an Access-Accept (without any mention of VLAN), then the IOS switch port config will be used that is currently configured on the interface. If you're using port templates, then it will be the config as seen with the command 

show derived-config interface blah/blah

[Nadav]

Hi,

I'll elaborate on the question with an example.

A workstation has connected to an access switch which performs 802.1x authentication via ISE. I would like the access vlan (pre-configured on the switch, not dynamic) to be sent in the access-request via RADIUS. This is in order to reach a policy based decision on the access-vlan.

For example, workstation connects to port Gi1/0/2. My RADIUS policy in ISE would treat it differently if the access vlan on that port is 2000 or 2010. 

This can be done today via the following commands (which automatically migrate all configuration to IBNS 2):

access-session attributes filter-list CUSTOM

  vlan-id

access-session authentication attributes filter-spec include list CUSTOM

I don't want this option, since I'd prefer not to go the IBNS route for my authentication configuration. I've confirmed this behavior on Cat9300 switches which prompt that applying these commands must irreversibly migrate the configuration to IBNS .

Another option that exists is via MAB, such as this:

mab request format attribute 32 vlan access-vlan

I don't wish to use MAB but rather 802.1x, so it's irrelevant.

This document gives examples of these use cases and others:

https://community.cisco.com/t5/security-documents/advanced-ise-tips-to-make-your-deployment-easier/ta-p/3850189 

Since the previous two options are unacceptable, I'd like to know whether or not there is a third option which doesn't require IBNS or MAB and that can be performed on 802.1x enabled interfaces.

[Arne Bier]

Oh I see. That's interesting. You want the port based authentication REQUEST to contain a hint to ISE in the form of an attribute that contains the VLAN of the access port on which the authentication is currently in progress.  Your examples already show how to do that using IBNS - but you don't want IBNS. I get it now.  I don't know of any non-IBNS way of doing this, while performing 802.1X

It looks like you have done a lot of research on this. Essentially what you need is this ... if it exists - I guess you have tried already?

dot1x request format attribute 32 vlan access-vlan

[Greg Gibbs]

Another option would be using the SNMP Query probe to gather the VLAN ID on the switchport via Profiling. You could then create policy that leverages the VLAN attribute based on custom Profiling Policies. This should even work for legacy switches that do not support IBNS 2.0.

See the ISE Profiling Design Guide for more info

Cheers,

Greg

[Nadav]

Oddly enough that doesn't send anything, as confirmed by packet capture.
Might be a bug, might be not implemented on this platform.

[Greg Gibbs]

It looks like the switch platform needs to support the CISCO-VLAN-GROUP-MIB in order to provide the VLAN information to ISE via the SNMP Query Probe.

You might want to have a look at the MIB support list for your platform on the MIB Locator page to confirm if it supports this MIB. If it does support the MIB, you might want to open a TAC case to investigate further.

Cheers,

Greg

[Nadav]

Thanks, that's some interesting information. Apparently the Cat 9k doesn't support it, which is very odd since these are the cutting edge platforms for the edge and this information would be most relevant for the edge.

I was hoping not having to go into creating profiling rules and using up Plus licenses just for this. 

As for the CISCO-VLAN-GROUP-MIB, is that also necessary for the RADIUS attribute to be sent along with the access-request during 802.1x authentication? Perhaps that's why it's not being sent?

[Greg Gibbs]

The MIB would only affect SNMP-based functions, so it would not be related to getting the VLAN info directly via RADIUS. Legacy IBNS uses the Auth Manager process, whereas IBNS 2.0 uses the newer Access Session Manager. Sending the VLAN was never a function of the Auth Manager process, so using the Access Session Manager (via IBNS 2.0; with the respective minimum IOS-XE code) is required.

As a note, IBNS 2.0 is the recommended option for switches that support it. If you are using (or plan to use) a Low-Impact Mode deployment, IBNS 2.0 implements a crucial enhancement for Critical VLAN. This was never a feature of Legacy IBNS and the only option was to use EEM scripts to attempt a similar function. Because the EEM scripts are based on logs, this did not consistently work in the vast majority of large production environments.

Cheers,

Greg