02-02-2017 08:10 AM
I have an IAP cluster, using Clearpass as the Radius server. The Captive Portal is on ClearPass Guest.
I have 2 services setup for accessing this network: MAC Authentication, and User Authentication with MAC Caching, listed in that order.
When a user connect to the Guest network for the first time, they fail MAC Authentication, and are assigned the Captive Portal Profile.
At the Captive Portal, you land on the login page, but have a link to go to the self-registration portal. if either a user connects with their AD account at the login, or creates an account to sign in, 2 scenerios occur:
1. after selecting login, they receive a DNS error, they cannot reach captiveportal-login.domain.com.
2. They are redirected back to the login page
Both scenerios have nothing show up in the Access tracker, outside of their initial MAC Auth failure.
The Captive portal profile is set to Clearpass, and the authentication server is set to clearpass and the accounting server is set to Clearpass.
The Guest login page has the correct URL listed for the wildcart cert being used on the IAPs.
It's difficult to debug as I'm not seeing the entry in the access tracker.
I'm also able to have the occasional user sign in successfully depending on their device. I just had a user unable to sign in on their laptop, but successfully sign in on their iphone using the same login credentials. MAC authentication works after initial sign in.
I've heard a bit about having the pre-auth check enabled in clearpass guest, and have a service associated to it, but lack understanding on what this does.
I'm in deseprate need for help on figuring out this problem. It has been ongoing for a while.
02-02-2017 08:24 AM
02-02-2017 08:27 AM
Tim, Yes to both. I pushed the cert to all APs in the cluster and the VC. the URL in clearpass guest is correct.
*.domain.com is the cert, and url is set to captiveportal-login.domain.com
02-02-2017 08:36 AM - edited 02-02-2017 08:36 AM
As an added note, I beleive i've only seen this captive portal issue occur on Windows 10 devices. I don't recall it occuring on anything else.
02-02-2017 08:56 AM
One thing you need to consider is opening a TAC and see if a Clearpass upgrade is required since you are running a very early version of 6.5
Get Outlook for iOS
Lead Mobility Engineer @ Integration Partners
AMFX | ACMX | ACDX | ACCX | CWAP | CWDP | CWNA
02-02-2017 09:44 AM
I'm unsure when the issue started, it coudl very well have existed day 1, btu the devices I've tested have consistantly connected, while others have not.
Something that happened just now:
I brought my windows 7 laptop up to a few guests who were unable to sign in from the captive portal. I found my laptop had the same issue. I then came back to my desk and tested again and I signed in successfully. 2 different IAPs on the same cluster.
I rebooted the IAP that was having the problem, and 1 guest could successfully sign in on their laptop, and so was I (I deleted my endpoint first to do the sign in process again), but 2 other guests were still recieving the same issue at the same location. I then had 1 of the guests try to connect on their phone, and they were able to successfully log in, while their comptuer still couldn't.
I've checked the IAPs settings and everything seems to be the same, except the IAP at my desk is set to preffered master (and is the master currently). The same wildcard cert is set as the current CP cert on all IAPs.
It's all very confusing. It could be a version issue since I'm on the early versions for the IAP, Airwave, and Clearpass.
02-03-2017 07:41 AM - edited 02-03-2017 07:43 AM
It looks like this issue may be resolved in the instant 126.96.36.199-188.8.131.52 release... but there is a discrepancy in Arubas release notes.
On the 184.108.40.206-220.127.116.11 Notes:
Symptom: Clients are stuck on the Captive Portal authentication page when they try to use external captive portal over HTTP.The fix ensures that the captive portal authentication is successful. Scenario: This issue was observed on IAPs running Instant 18.104.22.168-22.214.171.124 release and later versions.
On the 126.96.36.199-188.8.131.52 Notes, under issues resolved in previous releases for 184.108.40.206-220.127.116.11:
Symptom: Clients are stuck on the Captive Portal authentication page when they try to use external captive portal over HTTP. The fix ensures that the captive portal authentication is successful.
Scenario: This issue impacted all scenarios where captive portal is used and was observed in all IAPs running a software version prior to Instant 18.104.22.168-22.214.171.124.
One says before 6.5.0, and the other says it effects after 6.5.0
Can anyone confrim which release notes is correct?
02-06-2017 08:38 AM
The Documentation for the Captive portal Bug has been updated, it effects everything before 126.96.36.199-188.8.131.52. It does not effect 184.108.40.206-220.127.116.11 and later
02-07-2017 12:00 PM
I've ran some additional tests on multiple IAPs.
I'm able to use TLS authentication and MAC authentication at any IAP in the cluster.
I'm only able to do User authentication with MAC Caching at the virtual controller IAP (and rarely elsewhere). This is the authentication used when signing in at the captive portal.
Self-Registered guest accounts from any access point properly show up in Guest User Repository.
There are Access Tracker entries for MAC authentication at all IAPs, as well as 802.1x EAP-TLS. Only 4 IAPs show User Auth with Mac Caching in Access Tracker, 1 guest user at each, however that's only over a 7 day period, and we generally don't have many guests registering on this portal.
the VC IAP is the only one that is able to consistantly work correctly for User Auth on a captive portal.
02-07-2017 12:04 PM
Are you using Dynamic Radius Proxy (DRP) on your Instant APS?
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base