This is perhaps somewhat related but in a different direction:
We are currently authenticating users against AD to access the device registration page. The CapPort page and the auth source is configured within the Guest>>Administration>>OperatorLogins part of ClearPass; this triggers a WebAuth service with the sole purpose of sending a service disconnect upon device registration being completed. I have added the AOS-CX Port Bounce enforcement profile to this service but it does not trigger the port bounce. The reason it is failing, from what TAC said, is that the service is a WebAuth service that is negotiated between the client and ClearPass with no network access device information being included in the transaction, and therefore nowhere to send the port bounce.
Is there a way within this config to trigger the port bounce?
Or, is there a better way to AD auth Students to allow them to access the device registration portal and add devices for MAC auth network access?
Thanks in advance!
Not sure about your specific situation, but based on what you wrote the following may be useful to get better understanding:
Not sure which of the two parts you missed. If it is the second, what you could do is try a dummy redirect, like you configure the switch to only redirect a specific IP (for example 10.254.1.1 if that is not used in your infrastructure and put a DNS name like: reauth.my.domain to it), and redirect that to your ClearPass. Then instead of pointing your client for the WebAuth to your ClearPass, point it to http://reauth.my.domain; note the http! not https, and that will then include the client MAC into the URL.
With understanding of the above, other approaches may work as well, as long as ClearPass knows the client's MAC address both on the Guest/Login portal and on the network (MAC auth).
Thank you for your time and always helpful and clarifying explanations!
Between my question and your response I have come up with this working process that hinges on the device not being completely added to the Endpoint Repository. I will also work on the redirect approach you detailed which would potentially negate the need for some of this configuration.
Below is the working configuration I came up with to provide port bounce to Operator Login Device Registration clients. Please look this over and let me know if you see any issues with this approach:
port-access role Dorm-CaptivePortal
associate captive-portal-profile GU_Dorm_Ethernet
associate policy captive-portal-policy
aaa authentication port-access captive-portal-profile Dorm-CaptivePortal
associate captive-portal-profile Dorm-CaptivePortal
vlan access name ZagReg
port-access role Dorm-Intermediate
associate policy any
vlan access name Student
port-access role Dorm-Access
vlan access name Student
vlan access 555
port-access fallback-role Dorm-CaptivePortal
port-access onboarding-method concurrent enable
aaa authentication port-access dot1x authenticator
aaa authentication port-access mac-auth
client track ip enable
client track ip update-interval 300
On the router, the Student VLAN has "ip helper-address" pointing to ClearPass in addition to the DHCP server.
The ZagReg VLAN does not have the same IP helper.
Client plugs in and fails mac-auth and fallback happens allowing device to grab IP from 555 network which is routed on the firewall and only allowed to ClearPass and DNS.
show port-access clients
c 1/1/3 50:7b:9d:37:25:93 Success Dorm-CaptivePortal, Fallback
Foley-TEST(config)# show client ip
50:7b:9d:37:25:93 1/1/3 555 10.55.0.13
Captive portal is presented, login is completed and device is registered.
Enforcement profile condition 2: Dorm-Intermediate Role sent to switch assigning Student VLAN but port bounce does not trigger for some reason the first time so client retains CapPort IP addressing. Endpoint repository has MAC but not device category information from IP-helper. Reauth set to 10seconds for this role forcing the same service to trigger again finally resulting in port bounce.
Foley-TEST(config)# show port-access clients
c 1/1/3 50:7b:9d:37:25:93 mac-auth Success Dorm-Intermediate
50:7b:9d:37:25:93 1/1/3 156 10.55.0.13
Port-Bounce causes DHCP renew on Student VLAN resulting in the device category info being sent to ClearPass from IP-Helper. This triggers enforcement profile condition 1 and the Doorm Access role to be sent to the switch which is configured for 3600 second reauth without port-bounce.
c 1/1/3 50:7b:9d:37:25:93 mac-auth Success Dorm-Access
50:7b:9d:37:25:93 1/1/3 156 188.8.131.52
Do you have a ClearPass cluster? And are authentication running to another node than the publisher? In that case it can take a few seconds between the endpoint is updated and the updated endpoint information is replicated back from the publisher to all your subscribers. In Captive Portal you have the 'Login Delay' that specifically for that captive portal introduces a wait time to allow endpoint data to be replicated. There also is a global RADIUS CoA delay under the Service Config - Service Parameters - Async network service, that defaults to 2 seconds delay.
© Copyright 2023 Hewlett Packard Enterprise Development LPAll Rights Reserved.