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

[Adam Edwards < >]

Steve Murawski, couldn't they use credssp via powershell (from a Windows box
of course) to trigger the remote chef-client run? That would sidestep the
winrm gem.

A "hack" way to do this is to use winrm to run the following commands if you
have chef-client running as a service:

net stop chef-client
net start chef-client

When chef-client restarts, you'll get a chef run. The downside of course is
that you're temporarily turning off the chef service. There may also be race
conditions that make this less than desirable.

Push jobs is also an option here. Task scheduler will work, particularly
easy if you just want to fire and forget and don't need to get status back
when you initiate the task (just rely on the chef server for that).

Lastly, you could use some sort of 'trigger' in your chef-client run that
looks for some state -- a data bag, a git tag, something else, that you can
set when you want a manual chef run. It could be at the start of your
runlist, and would abort (without error) the chef run if the state weren't
there. Combine this with a more frequent background chef-client run (e.g.
Chef set up as a service) and you could get what feels like on-demand
execution.

Ultimately, I think this is a good justification for the "run me now"
feature for the chef service. A user could use winrm to run a command that
tells the service to run chef now. Steve, what do you think?

-Adam



-----Original Message-----
From: Nico Kadel-Garcia 
[mailto:
 
Sent: Wednesday, July 8, 2015 6:36 AM
To: 

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

Updating your config every 30 minutes on a high availability system is, I'm
afraid, begging to break core live services such as NFS, DNS, monitoring,
and authentication. The extra work to lock cookbooks to specific, tested
releases for all production environments is burdensome and quite rarely
done. And the potential for a single unexpected "obvious" and "safe" change
to knock out an entire network is quite large.

I refer especially to the DNS, authentication, and web service related
cookbooks. Restarting a DNS or web daemon will interrupt active connections,
and even a white space config change typically restarts the service. And a
one character error in a DNS or authentication configuration will prevent
the service from restarting.

It's gotten better for DNS, since some cookbooks now verify the config and
error out if it's broken. But few other cookbooks have this kind of check.

Nico Kadel-Garcia
Email: 

 
Sent from iPhone

> On Jul 2, 2015, at 15:44, "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
>>
>>
>>
>>
>>
>>
>>
>>
>>