Yet another works-fine-locally-but-looses-its-mind-in-a-remote-session problem.
I have a PS script that runs standard Windows command line ftp.exe to get a file. Works a treat when ran directly, however when ran remotely via Invoke-Command it suddenly leaves the files with the encrypted bit set.
If I then, in the same PS session (in the same script), run cipher /d on the file, I get Access Denied. However if I log onto the remote machine using the same account, I can decrypt it.
So, question the first, is this a "feature" of ftp.exe? I can't find anything suggesting as such, but no other method of creating a file seems to result in it being encrypted, so I'm left thinking it is an intentional act by the application, like it checks the logon type and encrypts if it a network logon.
Second, why can I not immediately decrypt it? Same account, same session.
The essential bits of the script in question:
#the ftp script is just open, user, binary, get, quit
& ftp -n -v -s:"$script"
& cipher /d "$file_path"
I realize this is probably a pretty obscure edge case, but I'll leave an answer just in case anyone runs into anything similar.
As usual, ProcMon has all the answers...
At my company %HOMESHARE% is set to a network file server (by some GPO I believe).
As ftp.exe is retrieving a file, it writes to a temp file and then once finished, copies it over to the specified location. Even after knowing this, one might expect %TEMP% to be used for such a purpose, but no.
I'm not quite sure exactly how ftp.exe goes about determining the temp file location, but when I'm in a PSsession, it chooses my Documents folder (%USERPROFILE% I suppose), but when I'm in an RDP session it uses %HOMEPATH%. So of course my Documents folder is set to encrypt new files and so the temp file is encrypted and gets copied over, but the file share is not so it copies over clean.
Also, while I have found nothing official stating this, it does seem that cipher.exe is completely ineffective for a network logon. If after entering a PSSession I create a new file with Set-Content and attempt to encrypt using cipher /e <file> it gives the same access denied. Same account over RDP encrypts no problem;