|
Thanks Paul. Brad, what do you think of trying Paul's workaround below? I actually like this better than my scheduled tasks approach. Both do essentially the same thing — use the current token's ability to launch a process with arbitrary capabilities that
surpass the current token's. In this way, the restrictions placed on tokens in winrm sessions are meaningless from a security standpoint (though still useful for preventing accidental DOS or other harmful side effects of remote execution).
Regardless of OSC vs.Private, you'll need a workaround like this to get winrm to do what you want here until we solve the ntlm / kerberos / sspi issues.
-Adam
From: Paul Morton - BIA <
">
>
Reply-To: "
">
" <
">
>
Date: Tuesday, June 11, 2013 7:10 AM
To: "
">
" <
">
>
Subject: [chef] Re: Re: Re: knife winrm browsing network shares
The root of this issue here is that access token created by winrm are marked "remote" by the server. This means that they cannot be used to access network resources. I am investigating adding credssp to the winrm library which would allow winrm to create
non-remote tokens-but this is a ways out.
In the vagrant windows gem we use a powershell script to wrap the process in a new user session which has an access token that is not marked as remote.
On Jun 11, 2013, at 7:04 AM, "Adam Edwards" <
">
> wrote:
To narrow down the problem, it would be good to know the following:
1. On what operating system / version are you running knife winrm?
2. What OS version is the target OS?
3. Is the target OS joined to a domain?
4. What OS is running on the machine that is the target of the net use
command (i.e. the "server" in "\\server\share")?
5. Is the machine that is the target of the net use command in the same
domain as the machine that is the target of the knife command?
6. Did you set basic auth to true and disable encryption? I'm not sure I'd
expect off-machine access to work in that case.
A short-term workaround is to use scheduled tasks -- if you're interested,
I can give you a specific example, though it would help to know what
you're trying to accomplish with the net use (e.g. run a script, copy a
specific file, etc.).
Problems here are most likely due to the winrm gems used by knife winrm.
Those gems rely on libraries on the system running knife, which could be
Windows, Mac, Ubuntu, etc., and the presence of the right libraries and /
or bug fixes on those platforms varies. We are currently investigating
specific issues with NTLM for instance to see if unreleased versions of
the gems have the improvements needed to make the NTLM scenario work,
hopefully we'll have some prescriptive statements about how to make this
scenario work.
A few more questions:
1. Rather than use knife winrm to perform net use, is this operation
something that you could do from within a Chef recipe that runs on the
target system? That could free you from limitations of WinRM.
2. You could probably use the recipe route via the RC version of
mixlib-shellout, which supports running scripts with alternate
credentials, or some upcoming changes to the Windows mount provider that
will be merged to master this week.
Regarding private vs. open source chef, I don't see anything here that
should make open source chef work differently than private chef. The
connectivity is really about winrm configuration on client and server, and
the winrm / ntlm gems and libraries on those systems, and finally knife
which ships with chef client and plugins like knife-windows that add the
winrm functionality to knife. The chef server code really is not involved
here.
Thanks.
--
Adam Edwards
Software Development Engineer, Opscode, Inc.
On 6/10/13 9:07 PM, "Brad Knowles" <
">
> wrote:
On Jun 6, 2013, at 3:00 PM,
">
wrote:
but get an "Access is denied" when doing dir \\\\filer\\share
I'm curious -- has anyone noticed what version of Chef they're using with
regards to these problems? At least some of the tickets we've seen
appear to indicate that the problems with winrm are more prevalent with
Chef 11.x, whereas Chef 10.18.2 seems to work fine.
But in our case there's also a difference between our using Private Chef
(based on Chef 11) versus the other site using the Open Source Chef, so
we're not sure if maybe this is a Private Chef vs. Open Source Chef
problem, or maybe a Chef 11.x vs. Chef 10.18.x problem, or what.
I'm also curious if people have looked at what version of
knife-essentials they're using? Some other problems we've seen might be
related to using older versions of knife-essentials versus newer ones, so
this is a dimension to the issue that we're also trying to track down.
If we can't get this problem resolved quickly, we might be forced to give
up on Private Chef and step back to Open Source Chef.
Yes, we are working the internal channels at Opscode, but getting more
information from the community would also be very useful.
--
Brad Knowles <
">
>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
|