08-06-2018 12:38 PM
In the ISE - f5 deployment guide it reads:
"If AD/LDAP account validation is requires as terms for determining RADIUS status, then it is recommended to return Access-Accept when the identity store is available and to lock down authorization for probe account as noted. There are implications to RADIUS failover that need to be considered on backend store failure, i.e. return Process Error versus Access-Reject and potential impact to the load balancing cluster as a whole. If AD/LDAP is down for all PSNs, then the NADs need to failover to different cluster since the VIP will be declared down."
In a scenario where there are two separate DCs each supported by a different f5/VIP and I would want to have an ISE cluster in one DC fail if AD wasn't reachable by ISE in that DC, I'm interpreting the document that a valid account should be set up that would return an Access-Accept via AD as opposed to making up a bogus account that would fail but return Access-Reject?
That's how the above paragraph from the deployment guide reads, but would not having a bogus account which returned Access-Reject be a good enough test to confirm AD functionality?
Solved! Go to Solution.
08-06-2018 04:20 PM
The benefit of a real account is that you get an access-accept back and it verifies that the External ID Store is also functioning correctly.
Using a dummy username will fail/access reject if the ID store is up or down.
08-06-2018 02:32 PM
08-06-2018 03:51 PM
08-06-2018 04:20 PM - edited 08-06-2018 04:44 PM
As the author, I can speak to intent. The intent of my design guidance was to:
I am not totally clear on the mention of bogus accounts. I suspect you are looking to treat bogus account as "User not found" and distinguish that from AD down as "Process error". I suppose that could work as well.
Craig
08-07-2018 07:08 AM
I typically use a dummy account, i.e. where user not found is set to Continue, but I also setup a specific Policy Set for my F5 RADIUS probes where the admission criteria is "Device Type = F5 AND username = <Dummy Account name>". So there is no way it can be abused elsewhere. Granted I am not checking the back end AD store.
08-06-2018 04:20 PM
The benefit of a real account is that you get an access-accept back and it verifies that the External ID Store is also functioning correctly.
Using a dummy username will fail/access reject if the ID store is up or down.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide