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

And from the right account to the mailing list…

Steven Murawski
Community Software Development Engineer @ Chef
Microsoft MVP - PowerShell
http://stevenmurawski.com [http://stevenmurawski.com/]
On 7/8/2015 10:10:07 AM, Steven Murawski smurawski@chef.io wrote:
Adam,

I’m loathe to recommend CredSSP in general, but in the abstract (either CredSSP or Kerberos delegation) via PowerShell might work. There are some API calls that will not work from a non-interactive context (like anything that hits Windows Update). Using PowerShell remoting though, doesn’t directly help the Provisioning or Test-Kitchen use cases, nor people managing cross-platform.

We could add “run me now” to the service, but why re-invent the wheel? Task scheduler already offers that. I’d look at adding a way to get real time stdout from the scheduled task when requested to run interactively (the service doesn’t offer that either).

Investing in the service is throwing good money after bad. “We’ve got a service, so let’s make it do x” rather than “something already does x, let’s use it”.

The service even provides less information about the state of chef-client than task scheduler. With the service it’s always “running”, but Task Scheduler will show when the job is running, when it’s not, and when the last run was. And you can turn on job history…

Steve

Steven Murawski — Community Software Development Engineer
— Microsoft MVP - PowerShell

262.299.0393 – smurawski@chef.io [mailto:smurawski@chef.io] – my: Linkedin [http://www.linkedin.com/in/usepowershell/] Twitter [https://twitter.com/StevenMurawski] GitHub [https://github.com/smurawski]
CHEF
CHEF.IO [http://chef.io/]
TM
chef.io [http://chef.io/] Blog [http://chef.io/blog/] Facebook [https://www.facebook.com/getchefdotcom] Twitter [https://twitter.com/chef] Youtube [https://www.youtube.com/getchef]
On 7/8/2015 9:04:28 AM, Adam Edwards adamed@getchef.com wrote:
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:nkadel@skyhookwireless.com]
Sent: Wednesday, July 8, 2015 6:36 AM
To: chef@lists.opscode.com
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: nkadel@gmail.com
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 :slight_smile:

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: chef@lists.opscode.com
Cc: ohaya@yahoo.com
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:
chef@lists.opscode.com
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

Steven, tell us how you really feel about the service. J

One other thought I had on that is to do both in one of two ways:

  1.   Make a cli interface similar to service controller to “start” and
    

“stop” a chef-client scheduled task

  1.   Use the existing service, but instead of it using CreateProcess,
    

just have it use task scheduler to trigger an existing chef-client
scheduled task.

In either case, you’d get “run me now” for free and some of the other
benefits of task scheduler.

Short term though, I think the “net stop / net start” approach is fine if
you have configured your system to use the service.

-Adam

From: Steven Murawski [mailto:steven.murawski@gmail.com]
Sent: Wednesday, July 8, 2015 8:11 AM
To: Adam Edwards; chef@lists.opscode.com
Subject: RE: [chef] Re: Re: Re: Re: Getting “Access denied” when use
mount in recipe and run chef-client remotely via winrm

And from the right account to the mailing list…

Steven Murawski

Community Software Development Engineer @ Chef

Microsoft MVP - PowerShell
http://stevenmurawski.com

On 7/8/2015 10:10:07 AM, Steven Murawski smurawski@chef.io wrote:

Adam,

I’m loathe to recommend CredSSP in general, but in the abstract (either
CredSSP or Kerberos delegation) via PowerShell might work. There are some
API calls that will not work from a non-interactive context (like anything
that hits Windows Update). Using PowerShell remoting though, doesn’t
directly help the Provisioning or Test-Kitchen use cases, nor people
managing cross-platform.

We could add “run me now” to the service, but why re-invent the wheel?
Task scheduler already offers that. I’d look at adding a way to get real
time stdout from the scheduled task when requested to run interactively
(the service doesn’t offer that either).

Investing in the service is throwing good money after bad. “We’ve got a
service, so let’s make it do x” rather than “something already does x,
let’s use it”.

The service even provides less information about the state of chef-client
than task scheduler. With the service it’s always “running”, but Task
Scheduler will show when the job is running, when it’s not, and when the
last run was. And you can turn on job history…

Steve

Steven Murawski — Community Software Development Engineer

                              — Microsoft MVP - PowerShell

262.299.0393 – smurawski@chef.io – *my: *Linkedin
http://www.linkedin.com/in/usepowershell/ Twitter
https://twitter.com/StevenMurawski GitHub https://github.com/smurawski

CHEF

CHEF.IO http://chef.io/

TM

chef.io http://chef.io/ Blog http://chef.io/blog/ Facebook
https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef

On 7/8/2015 9:04:28 AM, Adam Edwards adamed@getchef.com wrote:

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:nkadel@skyhookwireless.com]
Sent: Wednesday, July 8, 2015 6:36 AM
To: chef@lists.opscode.com
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: nkadel@gmail.com
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 :slight_smile:

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: chef@lists.opscode.com
Cc: ohaya@yahoo.com
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:
chef@lists.opscode.com
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

That really seems backwards…

Let me try to rephrase:
“We can use the existing service to run a scheduled task on a schedule.”

That just seems to add a layer of complexity over the whole issue. I really think having the service just invites more pain than it is worth and trying to backfill features into the service (with less visibility) is not worth the effort.

I have yet to hear the compelling business or technical reason for having the service other than “it’s already there”.

Steve

Steven Murawski
Community Software Development Engineer @ Chef
Microsoft MVP - PowerShell
http://stevenmurawski.com [http://stevenmurawski.com/]
On 7/8/2015 10:25:11 AM, Adam Edwards adamed@getchef.com wrote:
Steven, tell us how you really feel about the service. J
One other thought I had on that is to do both in one of two ways:

  1. Make a cli interface similar to service controller to “start” and “stop” a chef-client scheduled task
  2. Use the existing service, but instead of it using CreateProcess, just have it use task scheduler to trigger an existing chef-client scheduled task.
    In either case, you’d get “run me now” for free and some of the other benefits of task scheduler.
    Short term though, I think the “net stop / net start” approach is fine if you have configured your system to use the service.
    -Adam
    From: Steven Murawski [mailto:steven.murawski@gmail.com [mailto:steven.murawski@gmail.com]]
    Sent: Wednesday, July 8, 2015 8:11 AM
    To: Adam Edwards; chef@lists.opscode.com [mailto:chef@lists.opscode.com]
    Subject: RE: [chef] Re: Re: Re: Re: Getting “Access denied” when use mount in recipe and run chef-client remotely via winrm
    And from the right account to the mailing list…
    Steven Murawski
    Community Software Development Engineer @ Chef
    Microsoft MVP - PowerShell
    http://stevenmurawski.com [http://stevenmurawski.com/]
    On 7/8/2015 10:10:07 AM, Steven Murawski <smurawski@chef.io [mailto:smurawski@chef.io]> wrote:
    Adam,
    I’m loathe to recommend CredSSP in general, but in the abstract (either CredSSP or Kerberos delegation) via PowerShell might work. There are some API calls that will not work from a non-interactive context (like anything that hits Windows Update). Using PowerShell remoting though, doesn’t directly help the Provisioning or Test-Kitchen use cases, nor people managing cross-platform.
    We could add “run me now” to the service, but why re-invent the wheel? Task scheduler already offers that. I’d look at adding a way to get real time stdout from the scheduled task when requested to run interactively (the service doesn’t offer that either).
    Investing in the service is throwing good money after bad. “We’ve got a service, so let’s make it do x” rather than “something already does x, let’s use it”.
    The service even provides less information about the state of chef-client than task scheduler. With the service it’s always “running”, but Task Scheduler will show when the job is running, when it’s not, and when the last run was. And you can turn on job history…
    Steve
    Steven Murawski — Community Software Development Engineer
    — Microsoft MVP - PowerShell
    262.299.0393 – smurawski@chef.io [mailto:smurawski@chef.io] – my: Linkedin [http://www.linkedin.com/in/usepowershell/] Twitter [https://twitter.com/StevenMurawski] GitHub [https://github.com/smurawski]
    CHEF
    CHEF.IO [http://chef.io/]
    TM
    chef.io [http://chef.io/] Blog [http://chef.io/blog/] Facebook [https://www.facebook.com/getchefdotcom] Twitter [https://twitter.com/chef] Youtube [https://www.youtube.com/getchef]
    On 7/8/2015 9:04:28 AM, Adam Edwards <adamed@getchef.com [mailto:adamed@getchef.com]> wrote:
    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:nkadel@skyhookwireless.com [mailto:nkadel@skyhookwireless.com]]
Sent: Wednesday, July 8, 2015 6:36 AM
To: chef@lists.opscode.com [mailto:chef@lists.opscode.com]
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: nkadel@gmail.com [mailto:nkadel@gmail.com]
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 :slight_smile:

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: chef@lists.opscode.com [mailto:chef@lists.opscode.com]
Cc: ohaya@yahoo.com [mailto:ohaya@yahoo.com]
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:
chef@lists.opscode.com [mailto:chef@lists.opscode.com]
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 [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