Closed nut-3 closed 4 months ago
@nut-3 So how are those prompts retrieved from the server different from the one which we get via HTTP call in the challenge reply?
See for example TunnelConnector.process_auth_response
function. Server actually sends those prompts as needed back to us.
@ancwrd1 my case is that those prompts are totally different of what server info request offers. In case of Indeed auth, which requires entering TOTP first and password second, I get 'password:' in both cases which is quite misleading.
Also, I've set up a ssl intercepting nginx to capture ssl packets that original linux snx and windows CheckPoint client send. Original snx offers only RSA TOTP authentication in my case, and it seems to have a pre-configured prompt. Windows CheckPoint client upon connection initiation sends server info request to /clients/abc
and uses response to form prompts. This is only my case, don't know if it's a common windows client behavior.
Ok thanks for the info. I have made some changes because of the merged SAML support code:
@ancwrd1 hi ) I'm a little bit confused by recent patches. Right now on 1.0.0-rc* Indeed auth that I've been trying to make workable is not functioning even with ssl tunnel. Could you please create a release from https://github.com/ancwrd1/snx-rs/commit/3ccd539a5fafd063afe4da65db61885834a935f8 so me and my colleagues could continue to use snx-rs while I'm trying to figure out how to make Indeed auth work taking into account recent code changes? Thanks in advance.
May be you could open a separate issue to check it? I can make a release build for you and attach it there.
Hi again. I hope this one is the last PR to get snx-rs ready for mass adoption at my company ) Kudos for the project! Here I introduced possibility to fetch password prompts from server info. Windows ChackPoint client works same way, at least with our auth mechanisms - on connection initiation it first sends a
ClientHello
request and then populates prompts with data received. The feature is guarded by--server-prompt
flag, I made it on by default, but feel free to make it off by default. Also, I implemented connection status request to the daemon inServiceController::do_info()
, as default disconnected status kind of bothered me )