Passing creds

This topic contains 5 replies, has 3 voices, and was last updated by  Don Jones 2 years, 1 month ago.

  • Author
  • #38854

    Joseph Crosley

    I'm running the below script:

    #Set the files

    $originalfilehash = "\\Servername\C$\Windows\system32\file.txt"
    $recoveredfilehash = "C:\DR Test Recovery\file.txt"

    #Create the hash

    $md5 = New-Object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider
    $originalfilehash = [System.BitConverter]::ToString($md5.ComputeHash([System.IO.File]::ReadAllBytes($originalfilehash)))
    $recoveredfilehash = [System.BitConverter]::ToString($md5.ComputeHash([System.IO.File]::ReadAllBytes($recoveredfilehash)))

    #Compare the files

    if($originalfilehash -eq $recoveredfilehash) {"The file is consistent with the original"} Else {"Error: The file is NOT consistent with the original"}

    My issue is the server that the originalfile is on requires credentials as it in another domain. I know I can use get-credentials but don't know how to add this to the script.

    Any help?

  • #38856

    Don Jones

    It's "Get-Credential" :). Always a singular noun.

    The easiest is probably to map a new drive using New-PSDrive, which for FileSystem can accept a credential. Or, map a drive the old-fashioned way using NET USE. That way, the drive itself is mapped using the credential, and you can perform whatever file operations you need.

  • #38860

    Joseph Crosley

    That is going to work... I will map using the creds. set the file do the hash test and then blast the map away. Thanks

  • #38866

    Don Jones


    Well, you can define a [pscredential]$cred parameter in the script; if you make it Mandatory, it'll prompt for the credential if someone forgets to provide it proactively.

    The problem is that you're reading the file using ReadAllBytes(), which simply doesn't provide a means of passing credentials. If you can't map a drive – even temporarily – then none of the .NET Framework methods are going to work. All of them are built on the assumption that a mapped drive will be available to hold the authentication channel. That's the case with all of the -Item and -ItemProperty commands in PowerShell, too – they don't accept credentials, because the underlying PSDrive is supposed to deal with that.

    Mapping a drive using New-PSDrive _would_ work. You simply map it, perform your operation, and then unmap it. I do understand if you're not _allowed_ to do so for some reason, although that reason would be purely arbitrary and have nothing to do with the technology, or security, or whatever; mapping a drive is a native SMB operation. In fact, what you're already doing "maps" a phantom drive since all the Windows file I/O routines require a "drive" of some kind in order to run. The drive maintains the persistence handle for the SMB session.

    Bear in mind that a PSDrive is not the same thing as a "network drive" in Explorer. You're not going to get a single-letter persistent network drive by default. A PSDrive is, by default, a PowerShell-only construct.

  • #38867

    Paul Frankovich


    Always singular? Well, unless you're working with GPOs in Win7 vs 2012....

    Cmdlet Set-GPPermission GroupPolicy (2012)
    Cmdlet Set-GPPermissions GroupPolicy (Win 7)

    I know, bad example with the GroupPolicy module...

  • #38870

    Don Jones

    Which they fixed in 2012 ;). Yeah, I know, people break the rules sometimes. But that makes them lawbreakers, not exemplars.

You must be logged in to reply to this topic.