Better Integration with Secret Server Two-Factor

Hi,
This is an interesting request. We haven't checked how we could do a radius integration but this is something we want to do for the next major release.

Regards

A very good idea.
I have started using 2FA everywhere I can.

I too, would like this as well.

+1 on this, we use 2FA from HotPin with SecretServer, would be great to add this field in (pin + generated key) even if it is to be done manually.

Agreed +1.

I've done some investigation on this, we are trialing Duo with SS and if you use the AuthenticateRADIUS API from webservices and populate the "radiusPassword" key with the duo OTP it pulls back a valid auth token.

https://secretserveronline.com/webservices/sswebservice.asmx?op=AuthenticateRADIUS

If the RDM client could have a popup to enable entry of the OTP password to generate the token when needed that would solve this problem I believe - for Duo at least.

Hi,
Thank you for the investigation. I will assign this to Hubert. I will not be able to work on this next week but soon after.

Any update on this guys?

Hi,
Is it still for Duo at first?

Yep still for Duo, however I don't think it really matters to the API what backend 2FA solution is used.

Hi,
We have requested help from Thycotic and we are waiting for their answer.

Regards

We use AuthLite with a OTP (pin that changes every 30 seconds) for a dual factor RDP logon. To login we combine the OTP with the username username-OTP. I would love this feature. Another option is if we could just use the clip board as a variable.
I see two very workable sceneries:
Option 1) Prompt for the OTP (or anything you wish to use in a macro or variable). Then the user can be set to Username-$PromptResult$
Option 2) Let us use the clipboard content like a variable. I can easily get the pin on the clipboard. Then the username can be set to Username-$Clipboard$


This would be a very minor code change, especially option 2. I can actually make this work already by setting up all my connections as Templates. I then enter my OTP in the QuickLink field and can reference the username as Username-$QUICK_CONNECT$ and it works. This is OK if only one or two of you sessions use dual factor but it becomes cumbersome.
Meantime, since we can already use custom field values in the user name, can anyone provide how to do a macro to copy the clipboard into a custom (or any info field) field or prompt for a value and put that in the custom field? Then we can just reference that custom field.

@David, great thanks for the update, please keep us posted on progress as this is the only sticking point for us before we can implement a full scale trial.

Any update guys?

Hi,
It's really a sad story. We are still waiting for an answer from Thycotic. I hope they will help us this week.

No joy I assume? :/

Hello,

I have received some info from them, I will send that along to Hubert.

Hi,

We have integrated and tested Secret Server's RADIUS authentication in RDM. It works with a simple RADIUS password, but the API shouldn't care about which 2FA solution is used, as Myles said.

There will be a checkbox in Secret Server credentials that will allow you to specify if you want to use RADIUS authentication, and when you need to enter your login information, there will be a field to specify the RADIUS password, or whichever else 2FA solution is setup in Secret Server.

This will be available in the next RDM beta release. We'd appreciate some feedback on the feature once it's available.

Regards,

Thanks, Hubert!

Very interested in testing in your beta. When do you anticipate that being available and is there anything required to be able to participate?

Hi,
It's already available:

https://forum.devolutions.net/topic22500-remote-desktop-manager--beta.aspx

Hi Hubert/David.

Got round to testing this today, works great, but a bug i've noticed:

Edit Group/Folder -> Select Credential Repository -> Select SS instance -> Select From List

There is no option for RADIUS here so the auth obviously fails, can this be added into this screen too?

Cheers,
Myles

Another thing i've noticed, when you auth once with RADIUS, it doesn't store the token or keep the session open, instead, it creates a new connection on each item opened.

Instead RDM will try to re-auth using the same RADIUS password as last time.

This is very annoying as in the 2FA solution will always, for every new connection, show a failed auth attempt, then the user will be prompted to put in their password and RADIUS password again, and then auth succeeds.

However this happens for EVERY new session - in a playlist, it gets pretty ridiculous and irritating.

Is it possible to have the access token cached and use the same one until a re-auth is requested by SS?

(In SS we have webservices timeout set to 2 hours, so the token should be valid for that amount of time?)

Myles

Hello Myles,

You're right, we'll work on a fix for both of these issues, thank you. I'll get back to you when the changes are made.

Regards,
edited by Hubert Mireault on 6/12/2015

Great Hubert,

Thanks as-always for the excellent support!

Myles

Hello,

The two changes will be available in the next RDM version: the RADIUS password will now be prompted if needed when using "Select from list" and the token will be cached and checked for validity each time, reprompting if it can't be validated.

When the next beta version is available, could you give it a shot and see if it works as expected in your scenario?

Regards,

Awesome, thanks Hubert,

Will test it once i've got the update and report back with anything I find :)

Hello Myles,

Thanks for testing it out. If you have any more issues, just tell us.

Regards,

I'm curious -- could someone from Devolutions (or a user) confirm that this integration was working with Secret Server? Thycotic is telling us that the AuthenticateRADIUS call does *not* support MFA, but that doesn't sound right...

Hi Hubert is currently on vacation but from what I know their API allows us to provide the 2-factor and that's what we have added.

Regards

Have discussed further w/ Thycotic, and seems that our Okta-based integration is a two-step challenge/response process. In the first step, the username/password are passed to Okta, and only after that can we send back the MFA code.

Via the AuthenticateRADIUS call, obviously all the variables are sent through at once which Okta doesn't like.

So perhaps a change is needed on the Okta side, or a new Web Services call on the SS side... we're going to see if we can coordinate on getting all three of you together (unless that's something you already have a channel on).

Hi,
On our side we don't have anything planned for Okta. Let us know if you think that we can do something on our side but for now I don't see how we could call the SS API in two calls.

Nope, agreed. I think SS either needs to extend its web services API or Okta needs to modify how their RADIUS-based authentication works.

SS needs to extend their API, I have a ticket open with them (for duo push), but their feature releases are glacially slow.