ISE 3.1 - Enable Failed Authentication Protection

[sdiver]

I am running ISE 3.1, and trying to enable failed authentication protection to prevent Active Directory user accounts from being locked by failed PEAP authentication attempts to WiFi (while I'd love to disable PEAP authentication completely, for various reasons it's not going to happen). The configuration seems straightforward, however, I have the caveat that ISE is joined to two different Active Directory domains, which do not trust each other (eg. domainX.org and domainY.org).

Step 9 of the Cisco ISE documentation linked below, outlines that the Authentication Policy for the applicable Policy Set must use the Active Directory join point as the Identity Source. As I have two Active Directory domains in play, I am currently using an Identity Sequence as the Identity Source (eg. DomainsXY-AD_IdSeq containing DomainX-AD and DomainY-AD). However, Cisco's documentation states an Identity Sequence will not work, the Authentication Policy must use the Active Directory join point as the Identity Source.

https://www.cisco.com/c/en/us/td/docs/security/ise/3-1/admin_guide/b_ise_admin_3_1/b_ISE_admin_31_asset_visibility.html?bookSearch=true#task_fk3_zwc_xpb

Would configuring this be as simple as creating two different EAP-PEAP Authentication Policies under my Wireless 802.1x Policy Set, and pointing each one at a different Active Directory join point for their Identity Source? Obviously, if an account is found in the first Authentication Policy/Identity Source, it will not move to the second Authentication Policy/Identity Source, so there's a risk if a user exists on both Active Directory domains they may be unable to authenticate, but I'm not overly worried about that scenario.

As I'm a bit of an ISE novice, I'm struggling to wrap my head around this.

Thanks!
 

[Arne Bier]

@sdiver - you're right on the money with your suggested solution. As for the 100% match, if you don't have users that exist in both domains then there's no concern - the worst that will happen is that ISE has to always search the first domain, and if not found, continue to the next domain. ISE will stop searching when it finds the first match. 

If there is a distinguishing feature about the users from each AD Domain, then you could use that as an additional condition in the Authentication Policy, to make it a 100% hit. E.g. if it's Wi-Fi, is there a 100% link between the SSID used and the users' AD Domain? Probably not, and what about username format? Is there a prefix or suffix in the username that might give a reliable hint to the Domain required?  Users won't be supplying their UPN (User Principal Name) during PEAP authentication - but if they did, then you could select the correct Authentication Policy by checking the username suffix.

[sdiver · Accepted solution]

To update, we found a solution that worked for us, and thank you @Arne Bier for confirming we went about this the right way.

Under our Wireless 802.1x Policy Set, we pointed the original EAP-PEAP Authentication Policy at the DomainX-AD joint point (the original/primary of the two domains).

We then created a second EAP-PEAP Authentication Policy, with a condition requiring users of the secondary domain to enter their full UPN (something that wasn't required previously, but that we pushed them to do anyway...so there were limited issues with this). That second EAP-PEAP Authentication Policy was then pointed at the DomainY-AD join point.

This worked for getting the Failed Authentication Protection in ISE to work. ISE will now check the badPwdCount attribute in AD with each PEAP authentication attempt, and if that number is ≥ X (where X is the number we configured in ISE for the maximum number of failed attempts) ISE will not pass the authentication attempt to AD at all. So the user's AD account won't be locked if the credentials are bad, but they won't be able to authenticate their device to WiFi if the credentials are good either. At that point, the user would need to come see IT, or login successfully to an AD connected service to reset the badPwdCount, or get an unsuccessful login to an AD connected service (other than ISE) outside AD's reset lockout counter timer.