I was reading about this mode and it sounded like what I wanted to so but I’m not having much luck. First authentication done by 3rd party IdP is federated and 2nd factor is Duo. Problem is that I only have a username and. It password. But it seems that the duo radius server requires a password even when you do not have ad_client configured. Why? If we match a configured user and have successfully authenticated the first factor, why does Duo require both a username and password to be sent? Is there a way around this? Any help is appreciated.
Can you post an example
authproxy.cfg? I’m not sure how you’re trying to configure Duo.
Typically when someone uses
radius_server_duo_only their application or service is able to have separate primary and secondary authentication servers. So, primary auth is handled as it was before Duo, and you add Duo via RADIUS as a secondary authenticator.
In this config the Duo server doesn’t do any primary password verification, and the only “password” it verifies is 2FA, so the name of a Duo authentication method (e.g.
phone) or a passcode.
So if your whatever application or device does primary auth via LDAP or SAML or local users DB, and supports adding a different secondary authentication method, you could add Duo via RADIUS with the
I want my device (NetScaler) to completely handle primary authentication. I only want to pass Duo the username and then have Duo kick-off the secondary authentication. I have no password as the primary authentication is SAML. In the duo agent log I see:
2018-06-15T14:55:10-0700 [DuoForwardServer (UDP)] Received new request id 252 from (‘192.168.121.5’, 61383)
2018-06-15T14:55:10-0700 [DuoForwardServer (UDP)] ((‘192.168.121.5’, 61383), 252): login attempt for username u’email@example.com’
2018-06-15T14:55:10-0700 [DuoForwardServer (UDP)] ((‘192.168.121.5’, 61383), 252): Missing or improperly-formatted password
2018-06-15T14:55:10-0700 [DuoForwardServer (UDP)] ((‘192.168.121.5’, 61383), 252): Returning response code 3: AccessReject
2018-06-15T14:55:10-0700 [DuoForwardServer (UDP)] ((‘192.168.121.5’, 61383), 252): Sending response
So in this config, why is the Duo agent expecting a password? do I need to alter the device type?
My authcfg looks like this:
After a little reading, I think what I want is:
RADIUS Duo Only
Use a RADIUS integration which does not handle primary authentication credentials. The user’s passcode or factor choice, encrypted using the PAP mechanism, is submitted for the RADIUS password.
And with this I must pass the username as the password. So I presume that the user and the password are the same but cannot be null. I am going to try that now.
So I am still not having luck. All I want the Duo agent to do is prompt my on the registered device.
There seems to be no configuration where I can just pass the username to the duo radius agent to kickoff a 2FA auth request…
There are two things you may want to change on your cfg file.
- Remove the [radius_server_auto] section completely.
- Remove the client=duo_only_client from the [radius_server_duo_only] section.
Your cfg should look like this:
Thanks for your suggestion. I tried this, but Duo is still looking for a password:
2018-06-22T14:54:20-0700 [-] Duo Security Authentication Proxy 2.9.0 - Init Complete
2018-06-22T15:22:58-0700 [DuoForwardServer (UDP)] Sending request from 192.168.121.5 to radius_server_duo_only
2018-06-22T15:22:59-0700 [DuoForwardServer (UDP)] Received new request id 60 from (‘192.168.121.5’, 42864)
2018-06-22T15:22:59-0700 [DuoForwardServer (UDP)] ((‘192.168.121.5’, 42864), 60): login attempt for username u’firstname.lastname@example.org’
2018-06-22T15:22:59-0700 [DuoForwardServer (UDP)] ((‘192.168.121.5’, 42864), 60): Missing or improperly-formatted password
2018-06-22T15:22:59-0700 [DuoForwardServer (UDP)] ((‘192.168.121.5’, 42864), 60): Returning response code 3: AccessReject
2018-06-22T15:22:59-0700 [DuoForwardServer (UDP)] ((‘192.168.121.5’, 42864), 60): Sending response
Maybe I should remove the client type?
To avoid spending time on the wrong thing, you do not need to remove the
[client_type]. If only one client section exists (
[ad_client], etc.) then the server sections use it automatically. So, if you only have
[duo_only_client] present in the file then all the
[radius_server_xxx] sections will use
[duo_only_client] ig that’s the only client you have present in the file whether you specify it with
client= or not. So, the presence or absence of the client type is not the issue here.
The log output you’ve posted is an access attempt to
[radius_server_duo_only]. Is this Receiver or some other client? Did you follow these instructions: Citrix NetScaler Gateway - Alternate Instructions? This configuration is the NetScaler handling primary and Duo doing secondary auth only. If you followed these instructions, then browser access should hit
[radius_server_iframe] and Receiver should go to
As I previously mentioned, with
[radius_server_duo_only] the password is the name of a Duo factor or a passcode. If your SAML login experience does not provide the opportunity for the user to enter a Duo factor or passcode, then none is passed to the proxy server. That is why you may see the
Missing or improperly-formatted password message in the log.
You can try one of these two solutions:
Send all authentication requests to
[radius_server_iframe]on 18122. This assumes that Receiver will be able to display the Duo web prompt after showing the IdP web login page. I don’t know if this will work!
[radius_server_auto](so send the secondary auth traffic to 18123).
[radius_server_auto]will do an automatic push or phone call to a Duo user’s primary device when none is specified, which should get you past the missing password error.
Could you please clarify what you mean by “the password is the name of a Duo factor” and provide an example?
It means that you should see three fields at login: primary username, primary password, and then a secondary password or passcode field. You literally type the name of a Duo factor as the secondary password e.g.
pushto send an automatic push request to your phone, or
phone to call you, or
123456 as a passcode from a hardware token or generated by the Duo Mobile app on your phone.
Take a look at the second Receiver example shown here in the Duo user guide. This is the front end of that
[radius_server_duo_only] config described in the Citrix NetScaler Gateway - Alternate Instructions.
So in that second field the user types in the Duo factor info (described in detail in that user guide page).
It sounds like the SAML config never gives the end user a chance to provide a secondary password to the NetScaler, so you should not use a method that requires explicit input of a Duo factor as the secondary password. That is why I suggested
[radius_server_auto] which will do an automatic push or phone call if no Duo factor is passed on at login.
I can specify a password of “push” in the nfactor configuration so I will try that. I had tried radius_server_auto already but it erred out the same way, looking for a password. I do not want to prompt the user for anything. The assumption is that the primary auth is done at this point and we just need to kick off the secondary auth which should really only require a username and we are passing that. Thanks for your help thus far.
Update: this is working now though specifying “push” as the password only orchestrates a phone call. It does not seem to leverage the app. How do you force use of the app? Tried “push” and “sms” but both use phone cll method with radius_auto
Issue seems related to Caller Station ID passed in Radius. When I set to radius_server_auto, I get a phone call. When I set to radius_server_duo_client_only the auth does not succeed, though it does say in the user log that the method was not phone but rather duo push. The auth proxy log says that the caller id - my laptop IP address is invalid which I presume means it is not registered with the user?
I think you would benefit from a call to Duo Support so one of our techs can answer all your questions interactively. This forum is not intended as a substitute for support.
Calling station ID plays no part in factor selection. Edited to add - you get a phone call with
[radius_server_auto] because your phone isn’t activated for use with Duo Mobile.
[radius_server_duo_only] if you don’t want to specify a second “password” to Duo. But, if you typed push as the second password that would fail if your phone isn’t activated for Duo Mobile push (as evidenced by auto mode choosing to call your phone).
In order to use push your phone needs to be activated for use with the Duo Mobile app. Here are some instructions around that:
https://guide.duo.com/enrollment end user enrollment of a phone and activation of Duo Mobile for push requests.
Managing 2FA Devices | Duo Security Admin activation of a existing Duo user’s attached phone
Duo Enrollment - Enrolling Users | Duo Security all of the ways to enroll users. Note in particular the “Activating Users After Enrollment” section.