Just to get some clarification on the matter, are you using the Aerohive Client Management MDM tool? Or an external MDM vendor, if so which one? If it's onboard I suspect there's a problem with the Attribute number on the profiles. I can help you further if you supply me with some more info on the MDM and maybe a screenshot or two of the user profile and the MDM solution.
We are using AirWatch Mobile Device Management. There was a problem with the attribute profile initially as it was assigned via RADIUS. Customer then moved user to different group and also I've replicated his settings in our lab (no attributes used on RADIUS) but I am still assigned with the "default" attribute number. See below screenshot from SSID settings. I am using 3 User profiles (noticed that Guest is there when you enable user notification of noncompliant clients). Attributes are as follows: 3 for default - no access, 9 for guest and 50 for MDM users. Tried that also with default and MDM user only but same results. Device was assigned with "default" profile only
Here is also MDM configuration screenshot
looks like there is no device enrolled. (see below)
This is screenshot from my lab. I've just added "default" and main profiles so 9 is the default one and 50 is for MDM devices. I've registered my iPad with customer's MDM and using our RADIUS server. Everything else is exactly the same.
Any idea why it's completely ignoring my MDM settings?
2013-04-26 08:21:46 err ah_capture: [MDM] ah_airwatch_get_device_enroll_info: failed to query tenative URL from AirWatch server.(rc=8)
(extracted from this topic: https://community.aerohive.com/aerohive/topics/airwatch_aerohive )
Are you able to check this out? Because if this is the case, i would recommend to open up a Case with Aerohive and Airwatch (e-mail them on email@example.com) and refer to each others casenumbers.
I've checked CLI logs on the AP and found some interesting issue here but not the one you mentioned (was looking at the exactly same topic):
2014-11-24 16:03:56 info capwap: CAPWAP receive kevent AH_KEVENT_ITK_NOTIFY, eventid = 14, size = 129
2014-11-24 16:03:53 info ah_dcd: [MDM] CRL thread: the file /tmp/mdm_walled_garden_vendor_airwatch is not existed
2014-11-24 16:03:51 err ah_capture: [MDM] ah_airwatch_get_device_enroll_info: failed to query tenative URL from AirWatch server.(rc=9)
2014-11-24 16:03:51 info capwap: CAPWAP receive kevent AH_KEVENT_ITK_NOTIFY, eventid = 14, size = 117
Is it something wrong with Airwatch or Aerohive config? I will open a case with both and will see if they help.
This can be a local problem (maybe the right ports are not allowed from the AP's to the AirWatch API URL?) or an AirWatch problem (the API connection is not allowed). Thats why i would advice to open the two cases.
There currently are enrollment problems with the AirWatch/Aerohive combination (https://community.aerohive.com/aerohive/topics/download_airwatch_mdm_agent_for_enrollment).
I'm not sure, but this could be the root cause of your problem too.
I'm curious about the solution! Keep us updated :-)
We had an issue at a new deployment where the Airwatch MDM enrolment was not working correctly. We tracked the cause down to an issue with the 6.1r6a firmware where the REST API key was not being updated in the access points with delta updates. You can see this by making a SSH connection to the access point and checking the API key value in the running configuration against the REST API key in the MDM configuration in HiveManager. The line you are looking for in the access point running configuration is:
security-object [SSID Name] security additional-auth-method mobile-device-manager airwatch api-key xxxxxxxxxxxxxxxxxxxx
We had to do complete updates to the access points to update the REST API key.
I've checked that and API key value is correct. In my lab I have 6.2r1a version of HM and did full update for the first time anyway so I am afraid that's not my case :(
Not yet. Both Aerohive and AirWatch are dealing with that and checked whole config yet but it's still not working. Will update you once I have working solution.
Did you get something from the cases? MDM enrollment is working for a year but we are receiving the same logs below:
2015-07-13 11:43:28 info ah_dcd: [MDM] CRL thread: the file /tmp/mdm_walled_garden_vendor_airwatch is not existed
We are wondering what is causing these logs and is there a function which may not be working but we haven't noticed yet.
Solution our customer wanted to implement wasn't fully supported by Airwatch (sending attribute number after succesfull authentication) as they wanted to have non-MDM devices in guest profile and MDM devices in school profile. We gave up in the end as Airwatch solution wasn't working very well.
I think that they still use it for managing schools iPads but gave up on wifi authorization.
Thanks for the document.
It's been a long time and I don't quite remember what other issues we've had but I think that full network access for non-MDM devices was one of them. Funny thing is that it happened randomly. As we've used older HiveOS version that time, this may be now fixed.
Issue we've had was, that my customer wanted to push non-MDM clients to different user profile (Guest) and have MDM enrolled devices in the main school profile with full access to all resources.
Simple solution is to use attributes (similar to 802.1x) returned from MDM enrollment. After few months of different testing, Airwatch engineer finally told us that this is not possible as there is no such option in Airwatch.
It would be more than appreciated if anybody knows how to trick this to work?