The HP MSM wireless platform can be used with HP IMC UAM as radius server for user or guest authentication.
Inside the UAM Configuration, a user Access Service can contain multiple access scenario’s, like:
- IF user connects to SSID1, THEN allow access and push vlan 10
- IF user connects to SSID2, THEN allow access and push vlan 11
- IF any other condition (the default Access Policy), THEN deny access
So to make this work, in UAM, SSID Conditions can be defined and applied in the Access Services.
This would be an example scenario in a byod Access Service, the scenario shows the Access Conditions (IF) and the resulting Access Policy to apply (THEN):
Inside an Access Service, multiple Access Scenario’s can be defined, these scenario’s will be processed in the configured order (Priority). When no scenario is matching, the default will be used:
As a general rule, if you want to control where users will be connecting, the default will be set to the built-in “Access Forbidden” Access Policy, and the admin will use the scenario’s to enable Network Access for a limited number of situations.
Nice, job done. However …
The problem Part 1 : UAM SSID Condition Filter does not work
When performing this setup, you may notice that the scenario’s do not take effect, and that the user authentication will be based on the default Access Policy set in the Access Service.
This means that UAM does either :
- not receives connection parameters (through RADIUS access-request and accounting ) : Make sure to enable Radius Accounting on the MSM VSC.
- receives the connection parameters in an unsupported format : This would be the case here, so the next part will show how to update the format on the MSM.
This behavior can be seen in UAM :
- 1/ User cannot authenticate since there is no matching scenario in the Access Policy : To validate and test, change the default Access Policy on the User Access Service to a different Access Policy than the “Access Forbidden”. If none of the scenario’s match, the default will be used.
Change the Default Access Policy to some Access Policy which is normally used in the scenario:
This should allow the user access and shows there is some error in the Access Scenario condition matching.
- 2/ When the user tries to connect and it fails, it will be logged in the Auth Failure Log (sometimes the descriptions actually make sense 😉 ).
In the session details, the missing SSID can be discovered:
The problem Part 2 : MAC-Authentication format of MSM is not what UAM Expects
Most vendors support mac-authentication, which is very simple and will capture the connecting device mac-address. This mac-address will be used as username and password to submit a login request to the Radius server.
Note in this trace, the Radius secret was entered in Wireshark to support decrypting the password field (Edit – Preferences – Protocols – RADIUS – Shared Secret) in the display of Wireshark.
Now the MSM is doing something strange here, since it is adding Service-Type : Login to the Access Request packet. (This should be Framed in my opinion):
This Login service is normally used to handle management login request (like an admin or operator login to the console or web interface).
This can be seen in UAM in an unexpected log (well, it is expected, once you have seen the Login Service section), namely the Device Authentication Log:
OK, enough problems for now, time to fix the setup.
The solution Part 1 : Update MSM Radius accounting method
For UAM to understand the SSID to which a user is connecting, MSM must be configured to send the proper radius accounting information.
By default, MSM will only send the SSID using Colubris Vendor Specific Attributes, the Called-Station-ID contains the BSSID MAC Address of the Access Point by default:
These Colubris VSAs are not understood by UAM to detect the client SSID.
So the MSM VSC Config needs to be changed, and the Radius Accounting must be set to:
This will result in the Called-Station-ID field to be updated to the newly configured macaddress:BSSID value:
UAM will now be able to report the SSID the user is connecting to in the Access details log (and the Access Scenario with WIFI SSID Conditions will work as well now):
The solution Part 2 : Update UAM access device type for MSM Radius client
When adding an access device to UAM, the device vendor type can be selected. Although I would only expect this to impact the usage of Vendor Specific Attributes (VSA) for the RADIUS Client device, this is not the case.
The issue with the Access-Request – Service-Type (Login) should have been fixed at the MSM firmware (In my opinion), but the fix has been done at the UAM Radius server code. The fix has been specifically implemented on the UAM Device Type : HP General.
So make sure to select HP General for your MSM Controller :
So by setting the HP MSM Radius client to the HP General Device type, the mac-authentication will work.
Warning : the fix seems only implemented for the HP General device type. So when I defined a new Device Type for HPMSM (Vendor code 8744 from original Colubris) and set the HP MSM Controller to this new Device Type (in order to use for instance some Colubris VSAs), the mac-authentication failed again.
Long post to explain what could go wrong, bottom line to make it work:
- on MSM VSC, enable Radius Accounting and set Called-Station-Id to mac-address:SSID
- on UAM, set the Access Device Type to “HP General”
Hi, very good article. Do you know if it’s the same with UAM 7.0 E0203? There you can only choose HP(MSM) or HP(Procurve), there is no access device type HP General.
I have not tested this yet on UAM E0203. The fact that MSM and Procurve are now listed as 2 unique vendors (as opposed to 1 HP General), really makes sense to me, as they each have their own Vendor ID for Vendor Specific Attributes. I would expect now the HP MSM vendor type includes the mac-address service-type login fix/workaround, but would need to test this.
Thanks for the great post. I just finished testing UAM 7.0 E0202, and coincidentally, HP(MSM) does not work, but HP(ProCurve) properly reads the SSID. I have a case open now with support to discuss.
UAM 7.1 E302 w MSM 18.104.22.168 does not read SSID if Device type is HP (MSM) unless the called-station-id content is set to macaddress:ssid. If set that way then the scenario SSID option works fine. If setting HP(MSM) in UAM rather than HP(Procurve) offers some additional benefit then easy enough fix. Otherwise 6 of 1…
Is it worthwhile to create a device with Colubris vendor ID and populate the VSAs?
Can I use iMC UAM & EAD module to create NAC solution for my network. which include domain user, guest user and BYOD user.