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

[Tensibai Zhaoying < >]

Firing a scheduled task remotely is easy and get you rid of the whole 
credential replay needed from winrm. 

This method works since winnt4 (at least) and has been used for decades to 
trigger db stop and then server Shutdown when there's a power outage and 
batteries lifetime is running low (usually this was part of the weekly reboot 
task under nt4 :p)

This gives you the enforcement part on a regular basis + the ability to 
trigger a run on an event with a lot of way to trigger it (winrm may not be 
allowed to so this that's said, I'm unsure about the latest limitations ) 

In brief, this could be a way to solve your problem on both sides 
(credentials of the process and on demand ability) 

Le 2 juil. 2015 22:31, o haya 
<
 >
 a écrit :
>
> Steven and Tensibai (et al), 
>
> Thanks for the interesting comments and discussion. 
>
> With that, I think that my perspective is probably a little (maybe a lot) 
> different, which probably explains the differences in opinion.  
>
> In our case, we are not looking to maintaining an environment or 
> environments over time, but rather, our desire is to be able to deploy 
> specified environments kind of "on demand", mostly one-time events.  That 
> is why the winrm-type approach is/would be most attractive (and as I said, 
> "natural") to us. 
>
> Thanks again, 
> Jim 
>
>
> -------------------------------------------- 
> On Thu, 7/2/15, Steven Murawski 
> <
 >
>  wrote: 
>
> Subject: [chef] Re: Re: Re: Re: Getting "Access denied" when use mount in 
> recipe and run chef-client remotely via winrm 
> To: 
> 
 
>  
> Date: Thursday, July 2, 2015, 4:08 PM 
>
> So, I wasn't referring to 
> running part of the recipe as a scheduled task, but to 
> making the full chef-client run the scheduled 
> task. 
>
> > 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.  
> >The 
> general use case for Chef Client is to run in the background 
> on a schedule, validating the known good state of the system 
> and picking up changes when necessary.  This is usually 
> accomplished as a service (or daemon) or via a scheduled 
> task (or cron job).  On Windows, I find the task scheduler 
> the better option, as you have more flexibility in 
> determining the conditions you can run the task in, it 
> easily supports alternate credentials, can be run on demand 
> as well, and isn't treated as a service 
> logon. 
> There is an use 
> case for invoking chef-client over winrm (or ssh) via some 
> orchestration engine rather than running on a schedule, but 
> that means you'll have to deal with the limitations of 
> WinRM.  There are just too many "gotchas" in 
> running in the WinRM context.  Many Win32 APIs can't be 
> called from a non-interactive logon (which WinRM is treated 
> as) and you have the credential delegation 
> problem. 
> As for 
> setting up Chef to run as a service or scheduled task, the 
> chef-client cookbook ( 
> https://supermarket.chef.io/cookbooks/chef-client ;) can help 
> with that (though I don't think it wires up "on 
> reboot"). 
> Steven MurawskiCommunity Software Development Engineer @ 
> ChefMicrosoft MVP - PowerShell 
> http://stevenmurawski.com ;
>                                         On 7/2/2015 2:44:09 
> PM, Tensibai Zhaoying 
> <
 >
>  
> wrote: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 
> >   
> >   
> >   
> >             
>                       
> > 
>     
> >   
> >     
>     
> >                       
>           
> > 
>
>                                        
>
>                                          
>                                         
>