I am looking for a solution where I am authenticate the user with user cerificate and send authorization request to ISE.
ISE sends radius request to DUO Proxy. When I used [radius_server_auto] then it failes becuse of LDAP authentication.
Then I found this: Duo Authentication Proxy Reference | Duo Security
This seams to be good as it does not authenticate to LDAP. It forwrds the request to the DUO cloud but it fails with: “Denied - Invalid passcode” However I’am expecting push.
Do you have any idea, what could I try to autheticate user without password or passcode? Certificate + Push
In my testing with the ASA, certificate auth, and Duo it seemed that when you try to use “Certificate” for Basic/Primary Auth and an AAA server (Duo) for secondary auth you had to select the “Both” option on the Basic > Authentication settings page.
With that limitation, omething I tried that did “work” for certificate primary + Duo Push secondary was this:
Edit the AnyConnect Connection Profile to set the Basic > Authentication method to “Both” and set the “AAA Server Group” to the Duo server
Go to Advanced > Authentication and change the “Username Mapping from Certificate” options to enable both “Pre-fill username from Certificate” and “Hide username from end user”.
While still on the Advanced > Authentication page set the primary field under “Specify the certificate fields to be used as the username” to the certificate field that MATCHES THE DUO USERNAME.
I didn’t add any thing on Advanced > Secondary Authentication.
With this configuration the AnyConnect client only showed a prompt for a password. This is the “password” for Duo, so I typed “push” and connected after approving Duo auth from a system that has the Cisco certificate present.
From a system without the Cisco certificate, AnyConnect never presents me with the password entry prompt because certificate validation fails.
Note that I haven’t ever tried with ISE (and won’t for the purpose of this conversation), but hopefully that’s enough to get you started.
Thank you for your response. We have tested different variations and found 2 different scenarios what is working without requesting the password field.
Solution a: ASA Use primary authentication with certificate and send authorization request to the DUO proxy. Important: The authorization request should not be set for “authorize only”! The reason is simple: If the “Authorize only” turned on in a radius request, then the User_Password attribute does not sent. However the User_Password radius attribute is mandatory.
The easiest would be if we could set the Authorize radius request to send one of the following User_Password: [‘push’, ‘phone’]. Unfortunately it is not possible. It is using the username [CN] from the certificate for the User_Name, and the User_Password attributes.
So the proxy [radius_server_auto] receives the Radius request, but it needs to authenticate with something. [ad_client] will not work as the password is not correct (hopefully no one use the username as password ) so we could use [radius_client] to authorize the request even if the password authentication fails.
“pass_through_all=true” helps to send all the necessary attributes to ISE and it can send the Authorization back to the client. Once the proxy receives an “access accept” radius answer message from ISE it initiate the PUSH. Once its done, it forwards the authorization message to the ASA.
So this solution is working but ISE does not able to send Change of Authorization message to the Firewall. So this solution is a bit limited in features.
Solution b: This variation is similar to the previous solution with an extra twist. The Authorization from ASA goes to ISE instead of the Proxy. ISE uses an external Radius server to initiate the PUSH, so use the proxy. And the same “wrong” password reason the proxy sends the request forward to ISE again for final authentication. It answers for the request with “access accept”, The proxy receives it and initiate the PUSH. If Push authorized then replies to the first radius request to ISE. And ISE response back to ASA.
Yes, you can tell that solution is pretty mad! However it works. CoA is also working.
The ugliest part in this solution that the ISE receive the same radius session ID twice. And the logs will be 3 times more. Of course I would not recommend this solution to anyone. It was jut an experience.
I was working closely with Cisco Sales Rep from Hungary, who sent the first solution for us. And We also initiated a feature request to Cisco ISE as we could manipulate the Radius attributes for the external Radius server where we could add / modify the User_Password attributes. (This attribute is not available currently)
[duo_only_client] based on our experience still requires User_Password radius Attribute. It can be one of the following 3 options [‘push’, ‘phone’, ‘$DUO-Token-Code’]. Without these parameters it provides only radius errors like: Password missing, or password is malformed.
As I mentioned before if we could manipulate the User_Password attribute on ISE then we could use this solution easily. Cisco needs to modify ISE software. Also heard that the Proxy itself will be integrated to ISE. Who knows when.
This is what I wrote earlier:
“The easiest would be if we could set the Authorize radius request to send one of the following User_Password: [‘push’, ‘phone’]. Unfortunately it is not possible. It is using the username [CN] from the certificate for the User_Name, and the User_Password attributes.”
Unfortunately this can not be happening as the User_Password radius attribute can not be added nor modified in ISE at this moment.
This solution would fit with [duo_only_client]. I see it was not explicitly written in my earlier post. Sorry.