Thanks a lot, KevinR and Glenn! Was definitely the second-hop problem. Toband
On Monday, November 25, 2019 at 11:01:17 AM UTC+1, KevinR wrote: > > Yep you've run into the second-hop problem as Glenn mentioned. I tried > your script in a remote Powershell session and it has the same problem. > Basically the issue is that the credential cache is empty on the remote > machine (as a security precaution), which prevents you from use the > DefaultCredentials on anything but an interactive logon. > To work around this, you need to use any of the methods listed here: > https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/ps-remoting-second-hop?view=powershell-6 > > Be aware that for Kerberos delegation to work, you need to be > authenticated to the remote machine via Kerberos, which is something Bolt > doesn't typically do. > > -Kevin > > On Monday, November 25, 2019 at 2:15:27 AM UTC+1, Glenn Sarti wrote: >> >> Hi Toband, >> >> This sounds exactly like the Double Hop problem with WinRM authentication >> >> >> https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/ps-remoting-second-hop?view=powershell-6 >> >> >> >> https://blogs.technet.microsoft.com/ashleymcglone/2016/08/30/powershell-remoting-kerberos-double-hop-solved-securely/ >> >> >> https://blog.ipswitch.com/the-infamous-double-hop-problem-in-powershell >> >> You can test that this is the case outside of Bolt. Create a PowerShell >> session to the remote server and run the script within that session. >> >> There a few ways to work around this issue but it really depends on your >> environment. Note, that you may see a bunch of articles recommending the >> use of CredSSP, that should be your last resort though. >> >> Glenn. >> >> On Sat, Nov 23, 2019 at 3:09 AM Andreas Torbiörnsson < >> [email protected]> wrote: >> >>> Hi group! >>> >>> Hoping that someone can help me with an issue I'm having. It's in a >>> windows environment. >>> I'm trying to run a script on a remote windows machine using Bolt. The >>> script looks up the latest version of chocolatey from a on prem nuget feed, >>> downloads and installs chocolatey. >>> >>> Running the script with this command: >>> bolt script run .\chocolatey_install.ps1 --nodes winrm://xxxxxxx --user >>> userx--password --no-ssl >>> >>> It returns a 401 error when making a web request to the nuget feed, >>> using System.Net.Webclient from .Net: >>> Querying latest package from http: >>> //xxx.xxxx.xxx/DefaultCollection/_packaging/Testfeed/nuget/v2/Packages()?$filter=(Id%20eq%20%27chocolatey%27)%20and%20IsLatestVersion >>> STDERR: >>> $invokeArgs = @{ >>> : System.Management.Automation.MethodInvocationException: Exception >>> calling "DownloadString" with "1" argument(s): "The remote server >>> returned an error: (401) Unauthorized." ---> System.Net.WebException: >>> The remote server returned an error: (401) Unauthorized. >>> at System.Net.WebClient.DownloadDataInternal(Uri address, >>> WebRequest& request) >>> at System.Net.WebClient.DownloadString(Uri address) >>> at CallSite.Target(Closure , CallSite , Object , String ) >>> --- End of inner exception stack trace --- >>> at System.Management.Automation.ExceptionHandlingOps. >>> CheckActionPreference(FunctionContext funcContext, Exception exception) >>> at >>> System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame >>> >>> frame) >>> at >>> System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame >>> >>> frame) >>> at >>> System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame >>> >>> frame) >>> at >>> System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame >>> frame) >>> at >>> System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0) >>> at >>> System.Management.Automation.ScriptBlock.InvokeWithPipeImpl(ScriptBlockClauseToInvoke >>> >>> clauseToInvoke, Boolean createLocalScope, Dictionary`2 functionsToDefine >>> , List`1 variablesToDefine, ErrorHandlingBehavior >>> errorHandlingBehavior, Object dollarUnder, Object input, Object scriptThis, >>> Pipe outputPipe, InvocationInfo invocationInfo, Object[] args) >>> at >>> System.Management.Automation.ScriptBlock.<>c__DisplayClass57_0.<InvokeWithPipe>b__0() >>> at >>> System.Management.Automation.Runspaces.RunspaceBase.RunActionIfNoRunningPipelinesWithThreadCheck(Action >>> >>> action) >>> at >>> System.Management.Automation.ScriptBlock.InvokeWithPipe(Boolean >>> useLocalScope, ErrorHandlingBehavior errorHandlingBehavior, Object >>> dollarUnder, Object input, Object scriptThis, Pipe outputPipe, >>> InvocationInfo invocationInfo, Boolean propagateAllExceptionsToTop, List` >>> 1 variablesToDefine, Dictionary`2 functionsToDefine, Object[] args) >>> at >>> System.Management.Automation.ScriptBlock.InvokeUsingCmdlet(Cmdlet >>> contextCmdlet, Boolean useLocalScope, ErrorHandlingBehavior >>> errorHandlingBehavior, Object dollarUnder, Object input, Object scriptThis, >>> Object[] args) >>> at >>> Microsoft.PowerShell.Commands.InvokeCommandCommand.EndProcessing() >>> at System.Management.Automation.CommandProcessorBase.Complete() >>> + CategoryInfo : NotSpecified: (:) [Write-Error], >>> WriteErrorException >>> + FullyQualifiedErrorId : >>> Microsoft.PowerShell.Commands.WriteErrorException >>> >>> >>> >>> >>> Here are the relevant parts of the code: >>> function Get-Downloader { >>> param ( >>> [string]$url >>> ) >>> $downloader = new-object System.Net.WebClient >>> $downloader.UseDefaultCredentials = $true >>> >>> return $downloader >>> } >>> >>> >>> >>> function Download-Package { >>> param ( >>> [string]$packageODataSearchUrl, >>> [string]$file >>> ) >>> $downloader = Get-Downloader $packageODataSearchUrl >>> >>> Write-Output "Querying latest package from $packageODataSearchUrl" >>> NEXT LINE IS WHERE IT CRASHES >>> [xml]$pkg = $downloader.DownloadString($packageODataSearchUrl) >>> >>> >>> I have verified that userx is allowed to query the server. I have also >>> tested to manually move the script to the remote machine and run it locally >>> as userx AND THAT WORKS. >>> Does anyone know if there is a problem/bug when accessing the >>> credentials of the user running a script (through >>> WebClient.UseDefaultCredentials) when the script is run by Bolt? I can >>> think of many workaround, but I can't understand why this won't work. >>> >>> Cheers! >>> Toband, the frustrated developer >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Puppet Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/puppet-users/7d5f7bdd-fa0c-4d9e-b95f-59d6d9e0df61%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/puppet-users/7d5f7bdd-fa0c-4d9e-b95f-59d6d9e0df61%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c904061e-fbd7-4f9e-9c3e-d0a7ff717c4c%40googlegroups.com.
