New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Environments with proxy #43

Closed
f-bader opened this Issue Jul 3, 2018 · 19 comments

Comments

Projects
None yet
3 participants
@f-bader
Copy link

f-bader commented Jul 3, 2018

As of version 1.2.0.0 the armclient command does not support environments where a proxy server must be used to access the internet.

Even if the proxy is configured with netsh winhttp set proxy armclient does not use this setting.

It would be great if you could support this functionality in a later version of armclient.

@snobu

This comment has been minimized.

Copy link
Contributor

snobu commented Jul 3, 2018

Hmm, it should obey whatever gets specified in ARMClient.exe.config since it's a .NET console app.
Can you try the <defaultProxy> trick? - https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/network/defaultproxy-element-network-settings

@f-bader

This comment has been minimized.

Copy link

f-bader commented Jul 4, 2018

Hi @snobu I tried that out this morning but had no luck.

I placed the ARMClient.exe.config file in the directory C:\ProgramData\chocolatey\lib\ARMClient\tools\ but that didn't work.

Here is the configuration I used

<configuration>
  <system.net>
    <defaultProxy enabled="true">
      <proxy proxyaddress="http://proxyaddress:3128"/>
    </defaultProxy>
  </system.net>
</configuration>

I tried other variations of the config file as well.

At last I downloaded armclient directly and saved the file in the armclient folder in my download directory.
C:\Users\USERNAME\Downloads\ARMCLient\ARMClient.exe.config

I then used Process Monitor to check if armclient.exe uses the file. And for all I can tell it at least tries to use the data provided.

armclient_processmonitor

Do you have any idea what could be wrong? Is there any setting for debug logging?

@snobu

This comment has been minimized.

Copy link
Contributor

snobu commented Jul 4, 2018

@davidebbo @ahmelsayed Any code changes lately that could result in proxy bypass?

@f-bader If you run ARMClient with the verbose flag, what's the output, connection timeout or something else?

@f-bader

This comment has been minimized.

Copy link

f-bader commented Jul 4, 2018

@snobu I try to login interactively with armclient login. So no verbose flag there. The UI is just plain white and I can see that the connection attempt (netstat -an | findstr SYN) is directly and not using the proxy.

If I use armclient spn [tenantid] [appid] [appkey] everything works as expected.

Seems the proxy settings are only not working for the generated login UI.

@snobu

This comment has been minimized.

Copy link
Contributor

snobu commented Jul 4, 2018

Hmm that might call into the other binary the AADClient one, not sure. Try to add a .config for that one as well.

@f-bader

This comment has been minimized.

Copy link

f-bader commented Jul 4, 2018

I check with Process Monitor and found that the following ".config" files are checked

C:\Users\USERNAME\Downloads\ARMCLient\ARMClient.exe.config
C:\Users\USERNAME\Downloads\ARMCLient\ARMClient.exe.mda.config
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config

I also added the proxy configuration to the machine.config, this should work for any .NET Application on the client. But sadly it still won't work.

I also created .exe.config file for every executable in the directory, also without success.

The .mda.config file should not do anything regarding proxy settings, as far as I understood "Managed Debugging Assistants".

@davidebbo

This comment has been minimized.

Copy link
Member

davidebbo commented Jul 4, 2018

You can see the code here, and the whole UI logic is inside Microsoft.IdentityModel.Clients.ActiveDirectory. You should be able to repro the same outside of ARMClient by making a similar call.

It may be that the library just doesn't support proxies. See this question which hints at that.

@snobu

This comment has been minimized.

Copy link
Contributor

snobu commented Jul 6, 2018

I added HTTP proxy support (through `WebRequest.DefaultWebProxy`), looks like it affects all requests, project wide, including ADAL.NET, which is nice.

Checkout my snobu-proxy branch and build it or just download [this test build] for a quick run.

Usage:

set ARMCLIENT_PROXY=10.9.8.7:8080
armclient.exe login

I'll send a PR if @davidebbo greenlights this approach.

@snobu

This comment has been minimized.

Copy link
Contributor

snobu commented Jul 6, 2018

Scratch that. ADAL.NET still bypasses the proxy for the UI requests. Looking into it.

@snobu

This comment has been minimized.

Copy link
Contributor

snobu commented Jul 6, 2018

Looks like this isn't going to work with ADAL 2.x. Proxy support, was introduced fairly recently (ADAL 3.x).

I remember attempting to port this over to ADAL 3.x last year but gave up due to the way refresh tokens are currently being used. It's probably a good idea to look at that again, it's also relatively straight forward to go to .NET Core after that hurdle.

See if this works:

armclient azlogin

You'll need the az cli installed. That one uses Python ADAL, so it should work by reading HTTPS_PROXY. You still need your current proxy setup in place since the rest of ARMClient uses it.

Example:

set HTTPS_PROXY=http://10.9.8.7:8080
armclient azlogin
@snobu

This comment has been minimized.

Copy link
Contributor

snobu commented Jul 6, 2018

Correction, looks like the env var is called HTTPS_PROXY, now fixed in my previous post.

@f-bader

This comment has been minimized.

Copy link

f-bader commented Jul 6, 2018

armclient azlogin worked even without the environment variable set on my Windows machine.
Most likely because it is using the default browser.
But the currently released version 1.2.0.0 (zip and chocolatey) has no support for this option. I used the snobu-proxy branch build you had uploaded.

@snobu

This comment has been minimized.

Copy link
Contributor

snobu commented Jul 6, 2018

The master branch has armclient azlogin so it must be an older binary up on choco.

@davidebbo Can you push a release to choco at current HEAD?

@davidebbo

This comment has been minimized.

Copy link
Member

davidebbo commented Jul 6, 2018

Ok, just pushed a 1.3, but it can take time for Choco approval. I also uploaded it to https://github.com/projectkudu/ARMClient/releases/tag/v1.3. Can you verify that?

@f-bader

This comment has been minimized.

Copy link

f-bader commented Jul 7, 2018

Hi @davidebbo there is still no option for azlogin. I receive the error message Parameter 'azlogin' is invalid!. I checked the source code that you published and there is the option for azlogin in the Program.cs.

Output of the PrintUsage
image

@snobu

This comment has been minimized.

Copy link
Contributor

snobu commented Jul 7, 2018

Not sure what's going on there, maybe your environment is mixing up assemblies, try to remove all older copies from your choco bin directory and start over. Release 1.3.0 does have azlogin in -

image

@f-bader

This comment has been minimized.

Copy link

f-bader commented Jul 7, 2018

Sorry my bad. I started the AADClient.exe instead of ARMClient.exe

@snobu

This comment has been minimized.

Copy link
Contributor

snobu commented Jul 7, 2018

All good, ok with closing this one now?

@f-bader

This comment has been minimized.

Copy link

f-bader commented Jul 7, 2018

Yes, thank you all very much.

@snobu snobu closed this Jul 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment