[chef] Re: Re: Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm

[Tensibai Zhaoying < >]

In my opinion, running chef (or any Configuration management system) on 
demand remotely is an anti-pattern. 

If you're describing a state, the targeted machine should launch the check by 
itself periodically and try to fix itself as much as it can.

It's harder to compromise a network from a machine who will overwrite your 
exploits changes every 30 minutes and enforce you to restart your 
compromission from scratch over and over again. 

That's just my opinion too :)

Le 2 juil. 2015 21:29, o haya 
<
 >
 a écrit :
>
> BTW, I should mention that I have a ticket on a slightly "larger" question 
> and this came up right in the middle of that ticket, so I've conveyed info 
> on what I di to the support person (Vikas).  I also was wondering out loud 
> if maybe you guys might make something like a credential proxy or maybe add 
> that capability to the existing Chef Windows service.  
>
> Understanding that this is generically a Windows problem, it still seems 
> like both the scheduled task (if it worked for me) and the service 
> approaches are kind of "un-natural" (read: kludgy) ways to do this, but 
> that's just my opinion. 
>
>
>
>
>
> -------------------------------------------- 
> On Thu, 7/2/15, o haya 
> <
 >
>  wrote: 
>
> Subject: Re: [chef] Re: Getting "Access denied" when use mount in recipe 
> and run chef-client remotely via winrm 
> To: 
> 
 
>  
> Cc: 
> 
 
>  
> Date: Thursday, July 2, 2015, 3:24 PM 
>
> Hi, 
>
> Thanks for the info.  I was just about to post 
> that I've had some success today, but doing something 
> different... leveraging the Chef Windows service.  What I 
> did was set the user's credentials in place of whatever 
> was in that service (in my case the Windows domain 
> Administrator) and then let the service fire off my 
> recipe/cookbook.  I have to so some tweaking of the design 
> of my recipes to prevent them from re-running more than 
> once, but I was surprised that it works after that. 
>
> I had seen mention of using 
> task scheduler/schtasks before, and I would've tried 
> that for this situation, but when I was looking into how to 
> do processing across reboots, but even though I was able to 
> get the task scheduling part done, the recipes appeared to 
> run into the same type of access denied problems.  I fought 
> with that for a couple of days, and finally gave up on it.  
>
>
> In particular, I was doing 
> a recipe for deploying Exchange, and it required installing 
> some prerequisites and then a reboot and then the actual 
> installation.  So back then, I would have the first part of 
> the recipe create a scheduled task via schtasks, for the 2nd 
> part, but when the 2nd part, which was what actually ran the 
> setup.exe and psconfig.exe, ran, it kept throwing errors 
> indicating that something wasn't accessible. 
>
> So, at this point, the service 
> approach is the only approach that works for me. 
>
> Thanks again, 
> Jim 
>
> P.S.  I 
> kind of guessed that there wasn't something, but I 
> posted because the threads, etc I found on the credssp and 
> chef were a couple of years old, and was hoping that 
> there'd be something better by now :(... 
>
>
>
> -------------------------------------------- 
> On Thu, 7/2/15, Steven Murawski 
> <
 >
>  
> wrote: 
>
>   Subject: [chef] Re: 
> Getting "Access denied" when use mount in recipe 
> and run chef-client remotely via winrm 
>   To: 
> 
 
>  
>   Cc: "o haya" 
> <
 >
>  
>   Date: Thursday, July 2, 2015, 3:02 PM 
>   
>   
>         
>                               
>    You are hitting one of the 
>
> core challenges in dealing with Windows remote 
> management. 
>    The ruby WinRM gem, which we 
> use for knife-windows, 
>   doesn't support 
> CredSSP credential delegation (and there 
>
> are security concerns with that anyway).  A better 
>   workaround would be to create a scheduled task 
> that will run 
>   Chef Client and trigger that 
> from winrm (with schtasks 
>   /run).  This 
> gets around the logon type and credential 
>
> delegation issues running in WinRM provide. 
>
> The cause of the issue is that when you 
>
> land in a remote shell hosted inside WinRM (either WinRS 
> or 
>   PowerShell Remoting), you're 
> connecting to a service and 
>   that service 
> does not have the right to pass on your 
>
> credentials to other services/computers.  So when you 
> try 
>   to mount the outside resource, it 
> attempts to connect as the 
>   computer's 
> Network Service account.  The path around 
>
> this is either Kerberos delegation (which has 
> requirements 
>   on the client side and in 
> Active Directory) or CredSSP, 
>   which the 
> WinRM gem doesn't handle.  Task scheduler 
>   suffers no such problems (and is a better way 
> to run Chef 
>   Client - and closer to how it 
> should run in a production 
>   context. 
>   Steve 
>   Steven 
> MurawskiCommunity Software Development Engineer @ 
>   ChefMicrosoft MVP - PowerShell 
>   http://stevenmurawski.com ;
>                                 
>         On 7/1/2015 9:54:21 
>   PM, o haya 
> <
 >
>  
> wrote:Hi, 
>   
>   
>   
>   I have been implementing 
> some 
>   recipes/cookbooks for deploying and 
> configuring Sharepoint 
>   and Exchange onto 
> our Windows servers.  These servers would 
>
> be domain mmembers. 
>   
>   
>   
>   I was originally testing by 
> logging into 
>   one of the Windows server and 
> then running "chef-client 
>   -o 
> myCookbook" and was finally able to get them working 
>   this past week. 
>   
>   
>   
>   Both sets 
> of recipes expect the respective 
>
> installation files to be shared out from the domain 
>   controller and the recipes do a 
> "mount" to 
>   "Z:" drive, 
> and then the recipes do "cd 
>   z:\" 
> and then execute the appropriate .exe inside a 
>   powershell_script resource. 
>
>
>   
>   
>   As I 
> said, I got these recipes working this 
>
> week, but in the real world, we would want to trigger the 
>   cookbook/recipe execution remotely using like 
> "knife 
>   winrm", so I started 
> testing the recipes using 
>   "knife 
> winrm" this weekend, and, in both cases, I 
>   ran into similar problems with both sets of 
> recipes.  
>   
>   
>   
>   The first problem was that 
> the 
>   "mount" would fail with 
> "access denied", 
>   so I've 
> since tried (a) pre-creating the mapped drive 
>   outside of Chef and also (b) physically 
> copying the entire 
>   directories of 
> installation software to the local C: drive 
>
> and running the installations off of the local files. 
>   
>   
>   
>   Unfortunately, neither (a) nor (b) approach 
>   worked either.  These failures occur at 
> different points of 
>   the installation, but 
> my impression is that all the failures 
>   are 
> coming down to some kind of access denied or violation. 
>   
>   
>   
>   So, I've spent most of this weekend 
>   testing and researching, which lead me to find 
> some older 
>   threads and information on 
> things like credssp an 
>   "2-hop" 
> that seem to indicate that these problems 
>
> have been around for awhile, so I was wondering if 
>   there's some mechanism or configuration 
> that should fix 
>   he problem nowadays? 
>   
>   
>   
>   Also, I should mention that I'm tried 
>   setting the WinRM CredSSP to "true" 
> on both the 
>   server side and on my client 
> (Chef workstation) side, but 
>   that 
> hasn't made any difference. 
>   
>   
>   
>   Can anyone 
> here tell me how I can get these 
>
> cookbooks/recipes to work using "knife winrm"? 
>   
>   
>   
>   Thanks, 
>   
>
> Jim 
>   
>   
>   
>                                   
>     
>   
>         
>                                 
>