We have a situation that we are trying to get a handle on, so I thought I'd post here. We are running ISE 2.1 patch 3 and or common switches are 3850s running 03.07.04E. We have six PSNs, and two masters and loggers. Two of the PSNs are dedicated for wireless only. Our workstation are a mixture or Windows machines (AnyConnect with NAM), and OS X machines (AnyConnect but no NAM). At present we are only attempting this for wired connections. We'll expand this particular portal to wireless eventually.
Of our ~35,000 endpoints, approximately 65% are MAB-based, and 35% are based on Dot1X and Active Directory. NAM clients use EAP Chaining, and non-NAM clients use EAP-TLS.
The underlying scenario is that we are piloting two factor authentication (2FA). First factor is Active Directory, and second factor is RSA. At present, the entirety of the Dot1X clientelle (the 35%) will migrate from AD only to 2FA. At present, we only have a few stacks ~300 endpoints utilizing 2FA.
The three scenarios are as follows:
- User is presented the Guest Portal in question and they enter in their credentials to authenticate. Instead of the normal "Success" page, they are presented with a white screen. This occurs with either the built-in Success page and an external success page. We cannot use the option to forward the user to their initial URL, as the browsers on OS X do not appear to support that ability.
- The user attempt to authenticate and they are presented with wither a 400 or 500 error.
- The user attempts to authenticate and they are presented with a second identical portal page.
The third case appears to be related to an option we've been looking at re-authentication. We set the session timer to 12 hours, and at the twelve hour mark, the switch state is updated, and the session is presented with the portal URL. We believe that the first screen has a URL from a stale session, and when the user authenticates, the request goes to a different server, or the initial session has timed out. Most of the time, the user is able to authenticate after the second portal page.
In regards to the reauth process, we've also tried using the Idle Timer RADIUS Attribute, thinking that if a user were to log out but remain connected, once the Idle timer expires, the user would be forced to reauth. We do not find that the Idle timer ever decrements, so the session never expires. This occurs whether or not the user remains logged in, or logs out. I am leaning towards the belief that the Idle Timer is not very useful in an Ethernet environment, and is a hold-over from the dial-up days of yore.
We're interested in figuring out how to troubleshoot these conditions. If we disable the reauthentication option, it appears that Issue 3 goes away completely, Item 2 is greatly diminished, and we haven't seen Item 1 when reauth is disabled.
There also appears to be a five minute timer involved when the portal is displayed , or possibly when the URL for the portal is presented to the switch port.
We've upgraded to Patch 3, and we are about to implement Policy Sets to try to make the list of rules smaller for any given set. We currently have approximately 45 active rules, and some of them, the MAB rules could probably be consolidated.
We initially were putting a MAB order of dot1x MAB on the switch ports, but that didn't work at all, so we are not using auth order mab dot1x. Priority is set to dot1x mab.
Load-balancing has been an issue and we've gotten around that by 1) putting the wireless controllers on dedicated PSNs, and by 2) adding a batch-size of 1800 to the 3850s that are serving 2FA The non-2FA switches are not load-balanced, but the first server in the AAA group is rotated around. As we convert switches to support 2FA, we'll add the batch-size.
Cisco's guidance on batch-size is quite out-dated, as it states that any value greater than 50 is considered a "large" batch, and any value less than 25 is considered "small". As the variable can accept a value of over 2 billion, I'm at a loss. The value of 1800 we are using was trial and error.
