cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3820
Views
0
Helpful
20
Replies

RADIUS Token Failover with Duo Proxy Servers

Steven Williams
Level 4
Level 4

I don't think DUO Proxy matters in this case, but how does radius token Primary and failover server work. I can never get the authentication to access the secondary server. Timeout on primary is 60 seconds. Do I need to lower this? 

 

Policy says "if process fails [DROP]" I assume this means it would query the secondary server in the radius token. Doesnt seem to ever get there. 

2 Accepted Solutions

Accepted Solutions

Yeah is there is a soft failure on the Duo that would be a bit harder to detect. You are correct that is where front this environment with an F5 would be the correct answer since the F5 can do complex keep alive checks.



Good luck!


View solution in original post

Remote Access VPN using Cisco AnyConnect VPN module to a Cisco ASA head-end has different ways to use DUO as the MFA. If using SAML, then ISE only used in authorization but not in authentication. If using RADIUS, it depends on how DUO policies configured in Duo Admin panel, the configuration on the Duo Auth Proxy, and then the configuration of Network Access policies and elements on ISE.

Thus, please provide details how it's setup so the community may comment better how to adjust it, etc.

View solution in original post

20 Replies 20

paul
Level 10
Level 10

Did you make sure to crank up your RADIUS timeout from the network device to ISE to something like 120 seconds?  Is the first Duo really not responding?  Put a fake IP address in for the first Duo to simulate a not responding.  The timeout going to Duo needs to be 60 seconds+ because you need to allow time for the user to do MFA.  

I stop the DUO proxy service on the primary server. The ASA VPN device is set for 60 seconds time out to ISE.

The ASA timeout has to be longer than the timeout going to the Duo servers to allow for the failover.  Otherwise the ASA will timeout and start the process over and then ISE starts the process over.  I would set ASA to 120 seconds and the time out to Duo 60 seconds.  You have both Duos tied together into an identity source sequence?  Did you abandon the dual AD individual authentication rule setup?

So what ended up working was the Radius username attribute looking for domainA\ go to Duo Proxy 1 on port 1812 and then if user not found continue then hits a policy that says look for domainB\ and go to Duo Proxy 1 on port 18120 and if user not found then continue and the last policy is deny access. Thats the identity sequence.

 

There are two instances of RADIUS tokens, One for port 1812 and one for port 18120 and inside each token there is primary and secondary DUO proxy servers. Ideally it would be nice to get these behind my F5 to LB it and I will get there but have to get this going for now. 

Ahh perfect makes complete sense. In your RADIUS token definition did you define the secondary IP? If so is that what isn't working? You shouldn't be using an identity source sequence for this. You probably need to play around with the timeout on the Duo and attempts. For example if you have timeout set for 60 seconds with 3 attempts it will take ISE 180 seconds to timeout primary IP which is longer than ASA timeout.


I have it set for 60 seconds and 1 retries. The issue is I get like 5 Duo Pushes so the user is going to be so confused. Should I be creating two radius tokens, Duo Proxy 1 port 1812 and Duo Proxy 2 port 1812 and put them in a sequence together?

How can you get 5 pushes if the primary Duo server is down? I guess I am confused on that point. It sounds like the primary server is really not down. With 60 seconds and 1 retry you are at 120 seconds for ISE to detect the primary Duo is down. So if your ASA timeout is 120 seconds or less the ASA is going to give up. Play around with your timers and really make sure your primary Duo is down. Like I said put a fake IP in the primary Duo to test.


I mean a fake IP would probably work better, but the reality is that my server isnt always hard down, but maybe the service of DUO stopped so I need it to detect outage on that too. I need to better understand the timers it sounds.

Yeah is there is a soft failure on the Duo that would be a bit harder to detect. You are correct that is where front this environment with an F5 would be the correct answer since the F5 can do complex keep alive checks.



Good luck!


So back to this mind breaking topic.

 

Just recently discovered that if a user is configured in AD and NOT in Duo, they can login to the Anyconnect VPN without any issues. I assume its a design issue or a policy issue with how users are authenticated. 

 

There needs to be something that says if the user belongs to AD but doesnt have a DUO account then deny access but cant figure out how to do this with ISE? Is it a matter of the ASA needs to point to the Duo Proxy server and then Duo queries ISE for AD membership?

 

Remote Access VPN using Cisco AnyConnect VPN module to a Cisco ASA head-end has different ways to use DUO as the MFA. If using SAML, then ISE only used in authorization but not in authentication. If using RADIUS, it depends on how DUO policies configured in Duo Admin panel, the configuration on the Duo Auth Proxy, and then the configuration of Network Access policies and elements on ISE.

Thus, please provide details how it's setup so the community may comment better how to adjust it, etc.

ASA radius servers are set to ISE. Duo Proxies are set as radius tokens in ISE. 

 

In Duo admin panel, I have the vpn application set to use simple username normalization. 

Duo Proxies are configured with ISE Server IP as Radius server.

 

ISE Policy is set as follows:

 

IsePolicy.jpeg

Some of the challenges with this was we are authenticating users from two separate forest domains and the forests have a two way trust, So each user has to use their domain\username for it work for each domain. I couldn't get it to work with just username since the ISE server sits in one domain. 

 

If a user is not configured in DUO but tries to authenticate to the anyconnect VPN they can successfully authenticate and connect as long as they exist in the domain and ISE verifies that. I assume this is because the ASA looks to ISE directly so DUO verification is only after the user is verified in the Domain. Not sure though. 

 

Just to add...

In case you are using Duo Auth Proxy, then the RADIUS application in Duo Admin Panel may enforce a new user policy to deny access to any users not enrolled.

 

Screen Shot 2018-11-14 at 9.39.42 AM.png

That is set to Deny.