MSM with UAM (mac) authentication

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):

msm-uam-radius-acc-ac-intro

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:

msm-uam-radius-acc-ac-intro2

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:msm-uam-radius-acc-ac-ts

msm-uam-radius-acc-ac-ts2

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:

uam-as-failed uam-as-failed2

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.

msm-mac-auth

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):

msm-mac-auth2

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:

imc uam - msm bad radius accounting - device authn failed

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:

msm-acc-def

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:

msm-uam-radius-acc-change

This will result in the Called-Station-ID field to be updated to the newly configured macaddress:BSSID value:

msm-mac-auth-updated

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):

msm-mac-auth-updated-log

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 : msm-mac-auth-uam-dev-type

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.

msm-mac-auth-uam-dev-type2

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”
This entry was posted in IMC UAM, MSM Wireless and tagged , , , , , , . Bookmark the permalink.

6 Responses to MSM with UAM (mac) authentication

  1. Anders says:

    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.

      • Gary says:

        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.

  2. NeilR says:

    UAM 7.1 E302 w MSM 6.2.0.1 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?

  3. Dharmesh Prajapati says:

    Hi Peter,
    Can I use iMC UAM & EAD module to create NAC solution for my network. which include domain user, guest user and BYOD user.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s