01-16-2012 02:03 AM - edited 03-10-2019 06:43 PM
Hello
Is it possible to create on ACS5 rule which will:
1. Try to authenticate user in external database1 (radius)
2. When external database1 returns FAIL (because of bad password) ACS5 should try to authenticate user in another external database2 (radius)
Is it possible to have such scenario ?
Thanx
Solved! Go to Solution.
01-16-2012 02:40 PM
Hello,
The only database that will allow that behavior when configured first on an Identity Store Sequence would be RSA when configured to use Native SDI. It has a setting that reads as follows:
"This Identity Store does not differentiate between 'authentication failed' and 'user not found' when an authentication attempt is rejected. From the options below, select how such an authentication reject from the Identity Store should be interpreted by ACS for Identity Policy processing and reporting .
Treat Rejects as 'authentication failed'
Treat Rejects as 'user not found'"
You can select either of the above two options in order to determine how will the ACS interpret the failure returned from the RSA.
For LDAP, AD or any other external database, if the ACS does the query to the external database, finds the username but the failure is caused due to a "Bad Password" the ACS will exit the Identity Store Sequence and will deny access to the user.
The only way for the ACS to keep querying databases in an ID Store Sequence is that the user account is not found on the current database.
Hope this helps.
Regards.
01-18-2012 09:37 AM
Hello,
You will have to delete the user from the Old Database as soon as you create it on the New Database for the ACS to receive an "Unknown User" error and move to the next available database.
The problem is that if the ACS finds the user on the Old Database it will not move to the New Database and the failure would be reported as "Bad Password" as you stated on the beginning.
Regards.
01-16-2012 02:40 PM
Hello,
The only database that will allow that behavior when configured first on an Identity Store Sequence would be RSA when configured to use Native SDI. It has a setting that reads as follows:
"This Identity Store does not differentiate between 'authentication failed' and 'user not found' when an authentication attempt is rejected. From the options below, select how such an authentication reject from the Identity Store should be interpreted by ACS for Identity Policy processing and reporting .
Treat Rejects as 'authentication failed'
Treat Rejects as 'user not found'"
You can select either of the above two options in order to determine how will the ACS interpret the failure returned from the RSA.
For LDAP, AD or any other external database, if the ACS does the query to the external database, finds the username but the failure is caused due to a "Bad Password" the ACS will exit the Identity Store Sequence and will deny access to the user.
The only way for the ACS to keep querying databases in an ID Store Sequence is that the user account is not found on the current database.
Hope this helps.
Regards.
01-17-2012 12:02 AM
Thanx for detailed description for Treat Rejects as 'authentication failed'
I have one more question for Treat Rejects as 'user not found'"
So - if my first external database: LDAP or AD return Treat Rejects as 'user not found'"
next external database can be queried ? (or this functionality is also only for RSA SDI) ?
Thanx
01-17-2012 07:11 AM
Hello,
Unfortunately the Treat Rejects as 'authentication failed' and Treat Rejects as 'user not found' options only apply when configuring RSA (Native SDI). Those would not apply for any other External Database like AD or LDAP.
Hope this clarifies it.
Regards.
01-17-2012 11:08 PM
so - there is no way i could do a migration from one external database to another external database ?
(creating gradually new users in new database and deleting them from old database) ?
Thanx
01-18-2012 09:37 AM
Hello,
You will have to delete the user from the Old Database as soon as you create it on the New Database for the ACS to receive an "Unknown User" error and move to the next available database.
The problem is that if the ACS finds the user on the Old Database it will not move to the New Database and the failure would be reported as "Bad Password" as you stated on the beginning.
Regards.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: