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.

Summary

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”