Security

Ok, running into an issue when using Clearpass to log onto Alcatel-Lucent switches.

Alcatel uses radius vendor code 800 (Xylan) to return a few vsa's that are used to authenticate switch mgmt logons.

The kicker is, they need to be returned in hex.

No problem when using IAS/NPS, but I can't seem to return hex values in CPPM. 

I need to return values FFFFFFFF and 0007FFB3.

The default type of these vsa's is OctetArray. But I don't have a clue how to go from hex to OctetArray or even what exactly is OctetArray.

I thought about using unsigned32 but adding 4294967295 (for the hex FFFFFFFF) isn't allowed: "Value "4294967295" is not a valid unsigned integer".

So Anybody have an idea how to return VSA as hexadecimal types?

EDIT:

octet-array should take the Hex value as is.  Have you tried that.

Yes, tried that.

Octetarray value FFFFFFFF gets converted into some other big decimal (?) number: 4646464646464646 when looking at the radius access-accept with wireshark.

Settign the value to hex in NPS does give FFFFFFFF in wireshark.

I'm not sure if this helps but here are the settings for CPPM and alcatel that i have running at a customer site

1. To enforce a VLAN 1014 for the RADIUS request, send –

RADIUS: IETF:Tunnel-Type = VLAN(13)

RADIUS: IETF:Tunnel-Medium-Type = IEEE-802(6)

Radius:Xylan:Xylan-Auth Group = 1014

To return vlan and policy info I'm using user-network-profile (UNP) which is working correctly. 

What isn't working is the management logon to the switches with cppm as backend radius. 

I am not sure if CPPM can send that over in HEX, hopefully someone here or TAC can tell you for sure.    

I have no idea if this will work or if it is supported, but what if you were to export the Xlan dictionary file; then edit it so that your "octetarray" types were now string.    This way the attribute name and number are the same, but CPPM will send over whatever string you put in (FFFFFFFF) in this case.   I have verified this will work from CPPM's perspective (through Access Tracker), but not whether your switches will interpret it properly.

Before

After

Also, since you're updating the dictionary file, there is a chance it could be overwritten with updates.   You may run the question by TAC.  If you do, please let us know the result.

Doesn't work unfortunatly.

I do however get completely different results from you. 

1) I edited the exported xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TipsContents xmlns="http://www.avendasys.com/tipsapiDefs/1.0">
<TipsHeader exportTime="Wed Feb 27 14:33:02 CET 2013" version="6.0"/>
<Dictionaries>
<Vendor vendorEnabled="true" prefix="Xylan" name="Radius:Xylan" id="800">
<RadiusAttributes>
<Attribute profile="in out" type="Unsigned32" name="Xylan-Auth-Group" id="1"/>
<Attribute profile="in out" type="String" name="Xylan-Slot-Port" id="2"/>
<Attribute profile="in out" type="String" name="Xylan-Time-of-Day" id="3"/>
<Attribute profile="in out" type="IPv4Address" name="Xylan-Client-IP-Addr" id="4"/>
<Attribute profile="in out" type="String" name="Xylan-Group-Desc" id="5"/>
<Attribute profile="in out" type="String" name="Xylan-Port-Desc" id="6"/>
<Attribute profile="in out" type="Unsigned32" name="Xylan-Profil-Numb" id="7"/>
<Attribute profile="in out" type="String" name="Xylan-Auth-Group-Protocol" id="8"/>
<Attribute profile="in out" type="String" name="Xylan-Asa-Access" id="9"/>
<Attribute profile="in out" type="String" name="Xylan-Acce-Priv-F-W2" id="42"/>
<Attribute profile="in out" type="String" name="Xylan-Acce-Priv-F-R1" id="39"/>
<Attribute profile="in out" type="OctetArray" name="Xylan-Acce-Priv-R2" id="34"/>
<Attribute profile="in out" type="Unsigned32" name="Xylan-Access-Priv" id="16">
<ValidValues>
<ValidValue enumOrdinal="1" value="Xylan-Read-Priv"/>
<ValidValue enumOrdinal="2" value="Xylan-Write-Priv"/>
<ValidValue enumOrdinal="3" value="Xylan-Admin-Priv"/>
</ValidValues>
</Attribute>
<Attribute profile="in out" type="String" name="Xylan-Acce-Priv-F-R2" id="40"/>
<Attribute profile="in out" type="OctetArray" name="Xylan-Acce-Priv-W1" id="35"/>
<Attribute profile="in out" type="String" name="Xylan-Acce-Priv-F-W1" id="41"/>
<Attribute profile="in out" type="OctetArray" name="Xylan-Acce-Priv-W2" id="36"/>
<Attribute profile="in out" type="OctetArray" name="Xylan-Acce-Priv-R1" id="33"/>
<Attribute profile="in out" type="OctetArray" name="Xylan-Acce-Priv-G2" id="38"/>
<Attribute profile="in out" type="OctetArray" name="Xylan-Acce-Priv-G1" id="37"/>
</RadiusAttributes>
</Vendor>
</Dictionaries>
</TipsContents>

2) they do appear as strings

3) I added the values

4) my output does not give the string. The values I do get is also what I get to see with wireshark.

EDIT: after rebooting CPPM I do get to see the string values fffffff etc in the access tracker output. Wireshark however still sees the 'wrong' values.

I'm guessing it's about time to go bother TAC. 

forgot to mention, i had to restart policy manager and the radius service for the dictionary change to reflect in the returned attributes.   TAC is probably your best next step.

Hi Guys,

Anyone managed to resolve this?

I have similar issue that authentication is accepted by Clearpass and the problem lies with the return attribute from Clearpass.

Managed to get it to work with Juniper SBR.

Thank you!

FYI, filed a ticket for this issue and got back that this issue will be fixed in CPPM v6.2

A late but hopefully usefull update.

With a workarround this is now working.

Export the Xylan (vendor 800) radius dictionary and edit (at least) the following fields from OctArray to Unsigned32:

Alcatel-Acce-Priv-F-R1
Alcatel-Acce-Priv-F-R2
Alcatel-Acce-Priv-F-W1
Alcatel-Acce-Priv-F-W2 

Now import the edited dictionary again.

For the actual values to use in your service / role mapping / enforcement profiles take the HEX value and convert it to decimal value. If you hate calculus like me you can use a website like http://www.binaryconvert.com/convert_unsigned_int.html.

This decimal value is what you need to sent now.

While you are editing this dictionary also add the following, you'll need these if you ever want to authenticate OmniVista users:

<Attribute profile="in out" type="String" name="Alcatel-Nms-Group" id="20"/>
<Attribute profile="in out" type="String" name="Alcatel-Nms-First-Name" id="21"/>
<Attribute profile="in out" type="String" name="Alcatel-Nms-Last-Name" id="22"/>
<Attribute profile="in out" type="String" name="Alcatel-Nms-Description" id="23"/>

Be sure to restart your services after changing the radius dictionary. It will not work if you do not restart!

Find attached my new and improved (as in: usefull) vendor 800 radius dictionary. You might have to change the extention to .xml.

Attachment(s)

RadiusDictionary-vendor 800.txt   2 KB 1 version

I don't know the solution to this.

However, the fact that it converted your value from "ffffffff" to "6666666666666666" indicates that it has treated each "f" as a character and converted the ascii equivalent - ie 0x66.

I would be tempted to change your dictionary to from a "Octet string" to a "32bit unsigned" and see if this makes a difference

Regards Derin

Euhhm.. I gave the solution :P

Apparently it is now (6.2.4) possible to return HEX values (using the standard octarrays) by just adding 0x in front of your HEX value

So no more need to edit the dictionary. You might still want to add some attributes to the dictionary so you can also authenticated OmniVista users though. 

Don't forget to restart Policy server and Radius server services when you change anything about a radius dictionary

For completeness I've attached the complete correct dictionary and example enforcement profiles to push both full read-only and full read-write access for 6400 and 6850 switches. (just rename to.xml and import)

Attachment(s)

EnforcementProfile-6400ro-rw-6850-ro-rw.txt   2 KB 1 version

RadiusDictionary-vendor-800-octarray.txt   2 KB 1 version