msfreaks / EvergreenAdmx

Script to keep Admx files up-to-date.
MIT License
110 stars 14 forks source link

proxy authentication not supported #10

Closed EckeD closed 2 years ago

EckeD commented 2 years ago

currently the script does not support proxy authentication: EvergreenAdmx-ProxyError I guess it should be as easy as using switch "-UseDefaultCredentials" on the Invoke-WebRequest executions, and "$listRequest.Credentials = [System.Net.CredentialCache]::DefaultCredentials" on the [Net.WebRequest] ones. Maybe optional if a specific global switch is provided, like "-UseProxyAuth" or so.

msfreaks commented 2 years ago

I don't have a proxy server anywhere to test this unfortunately. How does this work with a scheduled task for local system for instance? or running using a service account?

EckeD commented 2 years ago

hi,

running both as Local System as well as with a service account works fine - as long as the proxy is configured to allow that. This is not something your script / tool must solve, but the proxy responsible has to do that (e.g. allow access for Domain Computers, which is Local System).

In the end it really boils down to allow an optional switch to provide the proxy credentials - and in most cases it should be enough to define the default credentials as I mentioned above. In company networks, it is rather uncommon nowadays to have to provide a specific account for proxy auth, rather than the currently logged in one. The only place where this still fails unfortunately is for the Firefox ADMX, as those seem to be on FTP, and the FTP component does not support proxy auth (I guess it only works using a SOCKS proxy without auth, but I'm no proxy specialist either).

So I would suggest to simply add an optional switch to the script to set the aforementioned default credentials switch for any WebRequest call, which should fix most proxy auth issues in company networks. Something like "-UseProxyAuth", and if that switch is set, use the above switches on each of the WebRequest calls.

cheers

msfreaks commented 2 years ago

Can you check what this returns for you (if anything) please:

# tests invoke-webrequest behind proxy
Invoke-WebRequest -Uri "https://msfreaks.wordpress.com" -Proxy ([System.Net.WebProxy]::GetDefaultProxy()).Address -ProxyCredential ([System.Net.CredentialCache]::DefaultNetworkCredentials)

Ideally test this in the context of the scheduled task for EvergreenAdmx (so local system, or a service account?).

If this works I will use that with a switch of -UseDefaultProxy. If it doesn't we'll see what else can be done :)

Thanks!

EckeD commented 2 years ago

hey there, Happy New Year at first ;) Unfortunately this only works if you have a static proxy configured. In our case however we do not use that, but instead have a so-called proxy PAC file configured which dynamically assigns the correct proxy etc. It would work if we used a static proxy. But, as I stated above, it is much easier than you think :) the "Invoke-WebRequest" command does provide a switch paramter "-UseDefaultCredentials" - so the following works fine: Invoke-WebRequest -Uri "https://msfreaks.wordpress.com" -UseDefaultCredentials

msfreaks commented 2 years ago

Tested and will be added to next version (soon!).

Thank you for your patience, and sorry I didn't get to this sooner :(

EckeD commented 2 years ago

Thank you for your patience, and sorry I didn't get to this sooner :(

better late than never ;) also you are doing this for free, so... :)