I made some progress, but the issue certainly isn't completely resolved. UAM is defiantely one of the more difficult/complicated NAC systems I've deployed. I'll break this into two parts:
First, at one point, with RADIUS, I did get the error you are describing. I belive I hadn't imported a RADIUS certificate for UAM yet and that was causing it. Once I generated a cert (had to add a Windows CA for this :( ), I think that was resolved.
Using PEAP/MS-Chapv2 against UAM as a RADIUS server: In one deployment, I found that I was sending the Called-Station-ID context in the wrong format. I was using the SSID group as an access condition to assign access scenarios in the access service assigned to domain users. Well, the SSID wasn't read correctly, and this triggered the "E63121::receive no packet from mschapv2server" error (certainly not very imitative of the issue...). Peter Debruyne's blog (http://abouthpnetworking.com/2014/01/10/msm-with-uam-mac-authentication/) put me on the right track here. I do get the same issue regarless of how the access devices are configured--HP(ProCurve) or HP(MSM). So once I changed the Called-Station-ID format in the VSC, it works, but it never works the first time. When no users have authenticated in about ~an hour, I always get the "E63121::receive no packet from mschapv2server" error on the first authentication attempt (the error log shows a blank next to the SSID field). After that one error, the next manual attempt will always work. Still working with HP support on this, but it's unusable for users. I've set up a NPS server using NAS-ID as a condition for RADIUS in the meantime. I suspect IMC work work fine if I removed the SSID as a condition, but it's pretty much required for the deployment.
On the guest/byod mac auth SSID: I have the same issue right now on two deployments. It was kinda working on 7.0 E203, but due to the guest self-registration bug mentioned in the patch notes (if they didn’t use self-service, users were getting something like a 'network problem' error on registration request), I since upgraded up to E203P04 then to E203H06 (had to request the newest versions from HP support--only E203P03 is posted to the web), and now I'm getting "E63053::Invalid authentication type" when a user is forwarded to the BYOD portal. When a user connects, I see the byodanonymous login with the correct mac address as the login name and the correct OS fingerprint, but that user gets the wrong portal page (they get the default HP-branded portal), with "The user is not online" under "User Information". No idea why the system isn't correctly associating the login. My setups are all fairly simple, with no L3 hops between the users, the authentication devices (MSM 460s) and the portal forwarding device (H3C switch or a VSR).
I'm relatively frustrated at this point, but let me know if this describes what you are facing. I'll continue to post updates, but I'm working on a few dozen projects at once, so they may be infrequent. Eventually, I'd like to get EAP-TLS functioning in IMC without iNode... but not for a while.
Gary
