Microsoft Vendor Specific Attribute - Vendor-Type 4170?

[Arne Bier]

This is a weird one.

But concerns me because I am migrating a customer's ACS 5.2 to ISE 2.2 and in one of their ACS Policy Results they include a VSA called MS-Tunnel-Tag inside the Microsoft VSA dictionary.  Customer performs a lot of dynamic VLAN assignments using 802.1X.  Microsoft mentions this VSA in this TechNet posting as being possibly required by some vendors, and I also see reference to 4170 in this posting about IAS (predecessor to NPS).

The weird part is that the Vendor-Type is 4170 (decimal) and this is (to my knowledge) illegal since the Vendor-Type may only be 0-255 since it's an 8bit field (see RFC2548).  Both ISE 2.2 and latest Wireshark conform to the RFC.  But our friend ACS 5.2 below allows >32bit values, including 4170!

The customer also uses a large fleet of Microsoft NPS servers (Radius platform) alongside ACS, and Tunnel-Tag is also there!

There is also an old Cisco Support posting where IAS is mentioned in context of this Vendor-Type.  I makes me think that it's not a complete fiction...

And used multiple with different VLAN values throughout their deployment

When I started migrating ACS to ISE I tried this and ISE doesn't allow this value.

When I did a Wireshark trace of the ACS Access-Accept packet I see that the 4170 is not found.  4170 is 0x104a (hex) and  it appears that even though it's configured as 0x104a, only the lower portion of the 32bit word is sent on the wire.

So it seems that ACS wrongly accepts values greater than 255?

I did a test by removing the MS-Tunnel-Tag from their lab ACS and there was no detrimental impact (the NAD is a WX5004 from H3C).

The other attributes that one commonly finds in these return policies took care of the VLAN assignment.

I am just wondering whether anyone knows if the MS-Tunnel-Tag was something historical?

And how is it possible that ACS and NPS allowed that Vendor-Type to be configured in a Radius Access-Accept policy?

[vibobrov]

4170 is an internal ID that NPS/IAS use to catalogue attributes. You can find in c:\windows\system32\ias\dnary.xml:

<Attribute>

<ID>4170</ID>

<Name>Tunnel-Tag</Name>

<Syntax>Integer</Syntax>

<MultiValued>0</MultiValued>

<VendorID>311</VendorID>

<Is-Security-Sensitive>0</Is-Security-Sensitive>

<IsAllowedInProfile>1</IsAllowedInProfile>

<IsAllowedInCondition>0</IsAllowedInCondition>

<IsAllowedInProxyProfile>1</IsAllowedInProxyProfile>

<IsAllowedInProxyCondition>0</IsAllowedInProxyCondition>

<LDAPName>msTunnelTag</LDAPName>

<IsTunnelAttribute>0</IsTunnelAttribute>

</Attribute>

Based on the packet capture in your screenshot, you're looking at VSA attribute (26/0x1a), Vendor Microsoft (311/0x137), Attribute 74 (0x4a). 6 is the length of the attribute, including ID, 00 00 00 02 is the value.

I can't find this attribute 74 in any Microsoft dictionaries i looked at.

ISE allows you to create custom attributes in the dictionary. Based on the length the type of the attribute should be UINT32.

[Arne Bier]

Hi Viktor

Thanks for the IAS c:\windows\system32\ias\dnary.xml reference.

Are you able to check

- whether IAS can return this value in a radius Access-Accept message to a NAS?

- what the radius packet looks like when it does so?

Yes - attribute 74 (0x4a) is not valid at all, and it's a result of chopping the WORD 0x104a in half!

I guess my point was that ACS GUI allows the user to enter some bogus value, and then the ACS UDP/Radius stack takes only the 8bits of that user-entered value (no bounds checking).

The Wireshark that I shared was taken from the ACS that sent the Access-Accept.

So my conclusion is that even if the customer's intention was to send MS-Tunnel-Tag (x104a) to a NAS, and ACS GUI allows the value to be entered, the resulting VSA that ACS puts in the Radius packet is garbage (0x4a).

Garbage in, garbage out?

cheers

[vibobrov · Accepted solution]

I tried this with my local NPS. Tunnel-Tag is listed under standard attributes, not under Microsoft.

When I use it in the policy, it does not make it into the RADIUS response at all. Perhaps it's used for some other NPS function beside RADIUS.

[Arne Bier]

Hi Victor

thanks for verifying the effects of this in NPS.  It helped me greatly.

cheers