Continuing on to next Identity Source upon AuthN failure from first Identity Source

[scott.stapleton]

I'm extracting this issue out of another post.

For CWA, I have an Identity Source Sequence setup with Guests first and an Ext. ID Source second. In some cases a user will have an account in each of the identity sources - Guests and the Ext. ID Source. If the user uses their Ext. ID Source login they will fail to authenticate in the Guests source but not continue trying to authenticate by the Ext. ID Source. I thought configuring the Authentication Policy to If Auth fail = CONTINUE would fix this issue however this option appears to be made for continuing to AuthZ, NOT continuing to the next identity source. If I reverse the order within the ISS, I will have the same problem but in reverse.

The Advanced Search List Settings option of Treat as if the user was not found and proceed to the next store in the sequence is not relevant here as this is NOT a case of the user not being found, the user is found, but it's a different user account and ISE needs to continue onto the next identity source despite the AuthN fail.

Is there a work-around for this?

[Arne Bier]

How do you think this type of ambiguity should be treated? I can’t figure out from your description where the issue lies. If a user exists in both Identity sources then how should ISE discern one from the other (based on what, and why?)

[scott.stapleton]

It's simple. If AuthN is successful from first ID. source, then move to AuthZ. If not successful, move to second ID. source.

The issue is that upon AuthN failure from the first ID source, ISE doesn't move to the next ID source.

[Surendra]

It has been the way on the ISE since the beginning. ISE will only fallback to another identity store if the user is not found but not on an authentication failure. A failure is a failure to ISE.

[scott.stapleton]

No work-around for this ISE limitation then?

[Surendra]

I wouldn’t count this as a limitation as such since it makes logical sense to reject a user if an authentication fails. For example, if a user is only present in the external store and fails authentication, it would simply be unnecessary to look at the user in another store. If authentication fails in one store and passes in another, how should that be counted? A failure or a success ?

[scott.stapleton]

Well I can't achieve the use-case I have so it is a limitation.

As mentioned, I have a use-case where I need to look in both stores; it's not unnecessary; it's simply unsupported in ISE. This is likely a corner case, but I simply wanted to confirm there wasn't a work-around.

Regarding your example, it should be treated as the user configures in the ISE GUI (by default failure, but with the option of configuring success), if this option were available.

[paul]

What is the second store?  Is it AD by any chance?  If it is then you just would have to coach the users to use an alternate AD account name format.  For example lets say there is a username in AD and guest database called user1.   Let's assume the email address for user1 is first.last@mycompany.com and the AD domain is mycompany.local.

If the user logs in with "user1" as the user ID you have a conflict and are in the situation you are facing, but there are many ways to specify user credentials when authenticating against AD:

mycompany\user1

user1@mycompany.local

first.last@mycompany.com

None of those formats should have conflict with the guest user database in ISE.  I am guessing your second source is not AD so this probably won't help, but wanted to post on alternative user name formats which could help if AD was the second source.

The other option would be to link to another portal.  The first portal is for true guests.  On that portal you can have a URL that links to a second portal that ties to the second authentication source.

[scott.stapleton]

Cheers - I was initially using username (there was only a single domain) however the powers that be wanted it consistent with guests.

Yes, second source is AD (well, LDAP).

Using UPN or any other format will cause usability problems so I'm going down the path of blocking corp. users from creating guest accounts with their AD email.

[hslai]

I posted a response to your original thread -- Confirmation of apparent ISE bugs & lim..