none
"Could not find a part of the path" after enabling PowerShell Transcription

    Question

  • I've just enabled the Group Policy "Turn on Windows PowerShell Transcription" and configured it with a UNC path to a shared folder to collect the session transcripts.

    The NTFS permissions for the folder are set as:

    • Allow Administrators Full control to This Folder, subfolders and files
    • Allow SYSTEM Full control to This Folder, subfolders and files
    • Allow Everyone Special to This Folder, subfolders and files

    where the special permissions are:

    • Read attributes
    • Create files/write data
    • Create folders/append data
    • Write attributes
    • Write extended attributes

    The share permissions are Everyone, Full Control.

    The machines are either Server 2012 R2 or Windows 10.

    If I fire up PowerShell on a machine and do some stuff, I get a transcript file being written to the shared folder.

    However, if I try and run something remotely, e.g. Enter-PSSession -ComputerName Server01
    then I get an error:

    enter-pssession : Processing data from remote server Server01 failed with the following error message: Could not find a
    part of the path '\\FileServer.domain.local\PowerShellTranscript$'. For more information, see the
    about_Remote_Troubleshooting Help topic.
    At line:1 char:1
    + enter-pssession -ComputerName Server01
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidArgument: (Server01:String) [Enter-PSSession], PSRemotingTransportException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

    If I start a remote desktop session on Server01 and fire up PowerShell, it is able to write to the PowerShellTranscript$ share - I get a PowerShell_transcript.Server01.HASH.timestamp.txt file created.

    It's only remote PowerShell stuff that the transcription isn't working for.

    Does anybody have any ideas?

    Thanks :-)

    Friday, March 3, 2017 1:48 PM

Answers

  • OK, so this is sadly caused by how PowerShell transcription works. This is not mentioned in the documentation, which implies you can just switch this on, point it at a share and start getting transcripts. Fail, because unlike other logging provided in Windows, PowerShell transcription tries to authenticate to the share using Kerberos double-hop, which unless you've done some prior configuration will fail.

    You can fix it in various ways, probably using (resource-based) kerberos constrained delegation (not CredSSP as that's generally considered to be a security liability).

    Blog post: https://rcmtech.wordpress.com/2017/04/06/powershell-transcription-to-a-file-share-breaks-everything-and-how-to-fix-it/ 

    • Marked as answer by robincm2 Thursday, April 6, 2017 5:10 PM
    Thursday, April 6, 2017 5:06 PM

All replies

  • OK, so I've just noticed that I have had some transcripts through, but only from domain controllers.

    I'm wondering if it's something in group policy, as the DCs get different policy to regular servers...

    Friday, March 3, 2017 1:55 PM
  • Second hop restriction.  You cannot access a share from a remote session.


    \_(ツ)_/

    Friday, March 3, 2017 7:15 PM
    Moderator
  • Really though? Rather defeats the object of transcription, namely to enable logging of potentially malicious activity...

    And why does it work OK on my DCs? I've yet to find anything that looks likely to be causing this different behaviour in a group policy (doesn't mean there isn't something, but nothing particularly stood out when I looked on Friday).

    Sunday, March 5, 2017 10:37 PM
  • Ypu can do this just not to a share.  The log must be local to the remote computer.

    If you use CredSSP then it will work.

    This s not a PowerShell restriction.  It has always been a Windows limit.  Ask your admins and network techs to explain how Windows networking works.  Fundamental Windows.  Some things cannot be done due to security and authentication restrictions.

    The fact the it works on a DC is because DCs are "trusted for delegation" by default which is why we need to protect DCs from access. This is also why we require network Admins to be certified. It is critical that all of this is understood completely.  To not understand this means that you cannot manage a Windows network securely or correctly.

    If you are just an end user or a desktop tech then you likely have not had this training.


    \_(ツ)_/


    Monday, March 6, 2017 12:27 AM
    Moderator
  • OK, so this is sadly caused by how PowerShell transcription works. This is not mentioned in the documentation, which implies you can just switch this on, point it at a share and start getting transcripts. Fail, because unlike other logging provided in Windows, PowerShell transcription tries to authenticate to the share using Kerberos double-hop, which unless you've done some prior configuration will fail.

    You can fix it in various ways, probably using (resource-based) kerberos constrained delegation (not CredSSP as that's generally considered to be a security liability).

    Blog post: https://rcmtech.wordpress.com/2017/04/06/powershell-transcription-to-a-file-share-breaks-everything-and-how-to-fix-it/ 

    • Marked as answer by robincm2 Thursday, April 6, 2017 5:10 PM
    Thursday, April 6, 2017 5:06 PM
  • No.  This is a fundamental restriction for all of Windows and has nothing to do with transcripts or PowerShell.  Take a bit of time out to do some reseearch on how Windows security and authentication work.  This is requirement for any Windows tech.

    \_(ツ)_/

    Thursday, April 6, 2017 5:09 PM
    Moderator
  • Well, actually, yes.

    I can do off-box logging in Windows in many ways and from many things, yet PowerShell transcription has been written in such a way that it does not work without additional security config. I know how the authentication works, the point I made, and which you're missing over and again, is that the double-hop restriction is not normally a problem.

    Security features need to be simple to configure to be effective. I can guarantee that I am not the only person who'll be annoyed at the faff involved in having to now maintain some form of KCD just to get the transcription working. Transcription didn't have to be coded to work like this, but because it was it will cause grief to many people and the uptake will be lower, and people will miss out on capturing valuable logging information. Disappointing.

    Thursday, April 6, 2017 6:21 PM
  • You miss the point.  There is no Windows process that can do a second hop without changes to fundamental security.  This has always been true of all Windows systems since the beginning. The issue is with the users lack of knowledge of the technology and has nothing to do with PowerShell.

    Just because you want something to be this way does not make it possible or a good thing. Windows is a complex technology. It does not cooperate well with out-of-band requests. This is by design and is one of the reasons Windows is so secure. Attempts to bypass this security remove critical security checks that allow hackers and malware to propagate.

    Windows is primarily about security. Convenience is always second as it should be.

    As I noted.  You cannot write a transcription facility that could bypass the security.  If that could be done what purpose would the security restriction provide. The restriction is enforced by the system. It cannot be bypassed.

    That said you can use CredSSP to allow this to work but that is not recommended and should only be implemented very carefully and with a complete understanding of the technology.  Also DCs are exempt but should be guarded and this should not be used arbitrarily.


    \_(ツ)_/

    Thursday, April 6, 2017 6:34 PM
    Moderator