Got to the bottom of the problem, and I needed an Aruba SE's eyes (thanks Roland!) to help because I'd basically gone snow-blind.
Oddly we couldn't replicate this in the office, and we did a load of tests across IOS, MacOS, IpadOS (has it's own problems), Windows and android.)
We have a 2 node cluster. It was upgraded to 6.11 about 5 weeks ago (by me). During the upgrade I built the new nodes on a build IP, then dropped the old servers and updated the 6.11.8 nodes to the IPs of the old server. This process went ahead correctly on one node, but incorrectly on the other....without me being any the wiser because I didn't realise how/where to check. The new IP was taken by the 'faulty' node, but the process that updated the db cert on one node successfully, didn't update the db cert on the other, so the SAN remained as the old build IP, when the mgmt IP had now been changed.
Release notes say this:
|
*
|
For a cluster with self-signed certificates, now after the user changes the management IP address they do not need to regenerate the database certificate. The steps to generate the database certificate and restart the backend service are now handled automatically.
|
From <https://www.arubanetworks.com/techdocs/ClearPass/CP_ReleaseNotes_6.x.x/Content/ReleaseNotes/Behaviors/Behaviors-6.11.0.htm>
That didn't turn out to be my experience, and if I'd had the wit and presence of mind to check a) the db cert or b) the Event Viewer for both nodes, I would have seen the problem pretty quickly.
I should have looked here
(In the image below the db cert has been updated to show the correct IP now.)
And I should have looked here
(In the image below the error message is telling me what the db cert should contain, but the actual IP was incorrect.)
Correcting the problem was easy enough - remove the node from the cluster (it was a subscriber), log in to CLI > system reset-server-certificate > option 3 for the db cert. Then log in to the GUI and 'Make Subscriber'
The Event Viewer wasn't the the thing that gave the game away, it just confirmed what was wrong.
The bit that gave the game away was noticing that if the publisher node updated a guest account that hadn't been purged, the account was handed a new expiry time 24hrs in the future.
If the subscriber node was dealing with the guest connection, and updating the account, that 24hr update wasn't making it to the guest record. So when the client did a new MAC auth, CP looked at the guest account, saw that it had already expired, and popped up the portal.
The Guest Application Log showed that the user account was being updated, everything on the Guest side looked fine.
(unfortunately these two images below only reflect what I was looking at, not the actual problem, as the dropping and re-adding of the subscriber got rid of all the messages for the subscriber from the PM access tracker log.)
The reality was that the Access Tracker (Policy Manager side) showed no such update, and reflected that the MAC-Auth Expiry had already passed.
The worst I saw was this happening to the same user 8 times in one day. And if the computer did a MAC Auth just 60 secs after registering, but if the publisher node caught the auth, the user was shown the portal again, at which point they'd re-register and this time the account would be updated correctly.
It's been a good problem to troubleshoot because CP isn't something I have to look into much, as the environment is very static, so it's forced me to have a pretty decent refresher of things.
Thanks for reading, and all the best.
------------------------------
Nathan
------------------------------
Original Message:
Sent: May 28, 2024 08:43 AM
From: Herman Robers
Subject: Apple devices, CP 6.11.8, captive portal, token, timer and expiry.
Nathan,
There are some known issues with design decision in these operating systems. One issue is that for SMS/Mail validation on the same device as which you want to connect with, when opening your SMS/Mail application, the captive-portal popup (mini browser) closes and there is no way to get back other than start over the same process which does not work as you would get a new code through mail/sms. On Android/Windows this is not an issue.
I don't have bullet-proof solution, but Aruba support may be able to help you with this.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: May 22, 2024 11:30 AM
From: n.millward
Subject: Apple devices, CP 6.11.8, captive portal, token, timer and expiry.
Struggling with Mac devices and the captive portal.
Visitor reported that they were using a Sonoma MacBook Pro, MacOS 14, registering on the portal, checking their email, clicking the self-sponsor link, and on the page that opened with the 'Confirm' button seeing that they were being given 48 hours of access - (the system is set to give Extend Expiration of +24 hours) - confirming, and then finding that they were having to register again within a short space of time, and register again several times in a day.
I've got a MacBook Pro for testing, Sonoma, and not been able to replicate the problem,
However, with my iPad running 17.5.1 I can 't get past the portal. First of all the portal doesn't pop up, I have to try to browse after connecting to the SSID. After getting to the portal and registering, I get the 'Please wait while we connect you to the network page' but instead of then getting the next page telling me to check my email, I get pushed back to a blank captive portal form. If I check my inbox on another machine, the email is there, and when I click the link the confirmation page is presented with a correct period of 24 hours access. But back on the iPad, if I fill the form out again, like a visitor might do, thinking that something had gone wrong, and submit a second registration, I get a second email, and this time the link takes me to a confirmation page where I'm granted 48 hours of access:
Another peculiar thing here is that the token in the email, never expires. Ordinarily the timer is around 10 mins before the client is pushed back to the portal if they don't confirm. And even though I've not clicked 'Confirm' at this point, the account session in CP indicates 24 hours access as if I have clicked the button, which is also at odds with what the self-sponsor confirmation screen shows.
If I delete the endpoint from CPPM and delete the account from CPG and try again with the iPad, and do the form only once, I'm bounced back to the empty form on the portal page, and given a new and correct account in CPG, pending clicking the 'Confirm' button which I can't get to on the iPad.
If I go to the email on another machine and click the link, firs of all it doesn't expire after 10 mins, and second of all, the self-sponsor page shows 48 hours!
So I don't know what's going on with the over-write of one registration with another, the 48 hours thing, and apple devices. What is it with apple? Am I falling into a hole with the CP database, or what?
Going round in circles now.
Thanks for looking.
Nathan.
------------------------------
Nathan
------------------------------