Dear Kristina,
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)
I hope you could follow the mentioned solutions.
Have a good day!
Gabor
Hello Kristina,
[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.
