Powershell: System.ComponentModel.Win32Exception (1312): A specified logon session does not exist. It may already have been terminated.

[brwilkinson]

Steps to reproduce

I have an issue similar to what was reported here: #10136 and #5868 (possibly others)

This feels/looks similar to a Double Hop problem, however It's intermittent and not specifically related.

Scenario

When I connect from one machine to the second using WSMAN, I am (intermittently) unable to map a drive to a 2nd hop file share, even though I am providing fresh credentials.

New-PSDrive fails with the error:

Exception:
System.ComponentModel.Win32Exception (1312): A specified logon session does not exist. It may already have been terminated.

FullyQualifiedError:
CouldNotMapNetworkDrive,Microsoft.PowerShell.Commands.NewPSDriveCommand

The strange things is that you can generally connect the first time, then never the 2nd time. However if you set the new-psdrive -scope local then you can connect the 2nd time and there after.

However if you connect the first time without -scope local and then you set -scope local the 2nd time, then you cannot connect. However if you wait a certain amount of time then you can connect again.

removing the pssession and creating that does not help. rebooting the 2nd machine and then reconnecting doesn't work, rebooting the client machine doesn't work.

Here is the code for the repro

$PS7ComputerName = 'AZC1ADFS1DC01'
$SAName = 'stagecus1'
if (!($Cred)){$cred = get-credential $SAName}
$root = "\\$SAName.file.core.windows.net\source"

# Test against PC 7 preview 6 . . works fine only the first time when not using new-psdrive -scope local.
$psSessionEndPoint7 = "PowerShell.7-preview"
$s7 = New-PSSession -ComputerName $PS7ComputerName -ErrorAction SilentlyContinue -ConfigurationName $psSessionEndPoint7 #-SessionOption $pso
$s7

icm -Session $s7 -ScriptBlock {
    $cred = $using:cred
    $drive = 'P'

    write-warning "hostname:  $(hostname)"
    write-warning "PSVersion: $($PSVersionTable.PSVersion.tostring())"

    if (-not(get-psdrive -name $drive -ErrorAction SilentlyContinue))
    {
        Try {
            New-PSDrive -name $drive -Root $using:root -PSProvider FileSystem -Credential $using:cred -Persist -EA Stop -Scope local | ft -auto
            dir "${drive}:\" -ErrorAction SilentlyContinue
        }
        Catch {
            $_ | select *
            #$_.exception
            #$_.exception.stacktrace
        }
        finally {
            get-psdrive -name $drive -ea 0 | remove-psdrive
        }
    }
}

Expected behavior - map the drive and list the files

WARNING: hostname:  azc1adfs1dc01
WARNING: PSVersion: 7.0.0-preview.6

Name Used (GB) Free (GB) Provider   Root                                     CurrentLocation
---- --------- --------- --------   ----                                     ---------------
P         7.17   5112.83 FileSystem \\stagecus1.file.core.windows.net\source

    Directory: P:\

Mode        LastWriteTime Length Name              PSComputerName
----        ------------- ------ ----              --------------
d----   9/5/2019  2:15 PM        AADAppProxy       AZC1ADFS1DC01
d----   9/5/2019  2:15 PM        ADConnect         AZC1ADFS1DC01
d----   9/5/2019  2:15 PM        AZFileSync        AZC1ADFS1DC01

Actual behavior

Once you remove the scope
E.g.

New-PSDrive -name $drive -Root $using:root -PSProvider FileSystem -Credential $using:cred -Persist -EA Stop #-Scope local

It will map the drive only 1 time, then it will fail again.

• adding the scope again does not fix the issue, unless you wait. then try again later.

WARNING: hostname:  azc1adfs1dc01
WARNING: PSVersion: 7.0.0-preview.6

PSMessageDetails      :
Exception             : System.ComponentModel.Win32Exception (1312): A specified logon session does not exist. It may already have been terminated.
TargetObject          : P
CategoryInfo          : InvalidOperation: (P:PSDriveInfo) [New-PSDrive], Win32Exception
FullyQualifiedErrorId : CouldNotMapNetworkDrive,Microsoft.PowerShell.Commands.NewPSDriveCommand
ErrorDetails          :
InvocationInfo        : System.Management.Automation.InvocationInfo
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 11
PipelineIterationInfo : {}
PSComputerName        : AZC1ADFS1DC01
RunspaceId            : 34e26d9a-f019-4d6c-bd25-15380f1c1629

Environment data

$PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.0.0-preview.6
PSEdition                      Core
GitCommitId                    7.0.0-preview.6
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[brwilkinson]

I am not sure if #7829 is also related...

Since it appears to map the first time.. it may be related to the cleanup of the old psdrive....

I would have to do more testing to know for sure.

[iSazonov]

See how configure delegation https://blogs.technet.microsoft.com/ashleymcglone/2016/08/30/powershell-remoting-kerberos-double-hop-solved-securely/

GoateePFE

PowerShell Remoting Kerberos Double Hop Solved Securely

The struggle is real. Are you facing issues with PowerShell remoting and credentials? You remote into your jump box, but then any remoting beyond there gets a big red ACCESS DENIED. Maybe you’ve tried CredSSP, but people say that isn’t safe. Read today’s post for a completely legit, secure, safe, and easy way to enable...

[brwilkinson]

@isazonov

Like I mentioned, this looks like double hop, however is not.

I am passing fresh credentials. It works with -scope local

Please try repro yourself.

[iSazonov]

Sorry, I skipped this.

However if you connect the first time without -scope local and then you set -scope local the 2nd time, then you cannot connect.

Look like the drive created in Global and did not removed.

However if you wait a certain amount of time then you can connect again.
removing the pssession and creating that does not help.

Looks like the drive is removed after timeout.

From the two comments we could conclude there is a resource leak.
But I don't understand:

rebooting the 2nd machine and then reconnecting doesn't work, rebooting the client machine doesn't work.

If you reboot client and server computer in the same time I'd expect all works. Can you add more info/repo steps?

[brwilkinson]

I cannot figure out a way to cleanup the leak, whatever it is, other than to wait. On my customer network, I haven't been able to clean it up at all. So this is currently a blocker to move to ps 7.

The repro is easy.

1) create Azure storage account and file share.
2) deploy 2 VM's with ps 7.
3) run the script above from the first machine to the second.

[iSazonov]

@PaulHigin Could you please look the issue?

[brwilkinson]

Thanks @iSazonov @PaulHigin ... please ping me if you have any q's on the repro etc.

[nwbatey]

I'm seeing this same issue when trying to create a new psdrive on a Windows 10 PC. I'm trying to remotely pull some files from a file share server directly to the PC. I'm running the following script:

$cred = Get-Credential $env:USERNAME
Invoke-Command -ComputerName workstation -Credential $cred{
    New-PSDrive -Credential $using:cred dummy -Root '\\fileshare\directory' -PSProvider FileSystem
    Get-PSDrive

    #Insert copy item commands

    Get-PSDrive -name dummy | Remove-PSDrive -Force
    Get-PSDrive
    }

The first time I run this, it successfully creates the drive and appears to remove it. Any subsequent time, it fails with the following error:

A specified logon session does not exist. It may already have been terminated
    + CategoryInfo          : InvalidOperation: (dummy:PSDriveInfo) [New-PSDri 
   ve], Win32Exception
    + FullyQualifiedErrorId : CouldNotMapNetworkDrive,Microsoft.PowerShell.Com 
   mands.NewPSDriveCommand
    + PSComputerName        : workstation

However, if I wait long enough it will be successful again. As mentioned before, it seems like some sort of timeout.

Let me know if you need any more info from me, or if you have any ideas on how to make this work.

[nwbatey]

I did a test this afternoon, and it takes 15 minutes before it will successfully run again. I realize this length may be configurable, but I thought it may be useful information.

[brwilkinson]

@nwbatey

yes that is interesting, I find the same thing.

Also did you try that workaround of using -scope local on new-psdrive.

it would work once the 15 minutes were up and should enable you do reconnect multiple times.

[nwbatey]

@brwilkinson

I did not exhaustively try that, but I will when I'm back in the office on Tuesday.

Just to clarify: You connect with -scope local the first time? the second and beyond times? or all times?

[brwilkinson]

@nwbatey

yes just leave -scope local on the whole time. . . I could repro connecting 100% of the time with that. However I actually couldn't get that working with one of my customers environments.

[nwbatey]

@brwilkinson

Ok, I want to say I already tried that and it didn't work, but at this point I can't remember all that I've tried haha

I will be sure to test it again next week and report back what I find.

[nwbatey]

The -scope local workaround did not work for me...

[brwilkinson]

@nwbatey are you using a windows file share or Azure file share ?

[nwbatey]

@brwilkinson It's a windows file share

[PaulHigin]

@brwilkinson
In your repro, you create the the PowerShell drive with the -persist parameter switch. However, it doesn't seem to make sense to create a persistent drive in a remote session. Once the remote session is closed the drive mapping doesn't need to persist, and creating a new remote session means having to create a new drive mapping, correct?

[brwilkinson]

@PaulHigin The reason for Persist is to create a drive that is visible to apps outside of PowerShell. E.g. robocopy. Since we are synching down application files, we prefer robocopy to only copy changes.

At the end we can remove/cleanup the drive, ... however while it is present it has to be a a standard mapped drive.

[PaulHigin]

Got it. Thanks.

[adityagulavani]

I'm seeing a similar error when trying to map a remote Linux drive.

This feels/looks similar to a Double Hop problem

I'm leaning towards this as well. Although I haven't been able to reproduce the issues with -Scope or -ConfigurationName, I can see that w/o CredSSP or -ConfigurationName I get the same error. Maybe an issue when setting PSConfiguration + Credential Delegation?

I've tried the following:

1. -SSHTransport

ICM -HostName Windows1 -SSHTransport -ScriptBlock {
    $cred = <create pscredential object>
    New-PSDrive -Name L1 -Root \\Linux1\root -Scope Global -Credential $cred
}

smbd logs show username received = ""

1. w/o CredSSP or -ConfigurationName

$cred = <create pscredential object>
ICM -ComputerName Windows1 -Credential $cred -ScriptBlock {
    $cred = <create pscredential object>
    New-PSDrive -Name L1 -Root \\Linux1\root -Scope Global -Credential $cred
}

smbd logs show username received = ""

1. w/ CredSSP or -ConfigurationName

$cred = <create pscredential object>
ICM -ComputerName Windows1 -Credential $cred -Authentication CredSSP -ScriptBlock {
    $cred = <create pscredential object>
    New-PSDrive -Name L1 -Root \\Linux1\root -Scope Global -Credential $cred
}

smbd logs show username received = "root" (Correct)

I'm not sure where we can retrieve similar logs for Windows, but if we can check the Credentials received, we can pin point the issue.

[brwilkinson]

@adityagulavani

How are you creating your $cred ?

Are you using the $using:username and $using:password or just hard coding your values?

are you using convertto-securestring?

[adityagulavani]

$pass = ConvertTo-SecureString -String 'pass_plain' -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList 'user01',$pass

Will give it a try with $using.

Edit: Getting same results as before with $using

[brwilkinson]

okay no problem, i just wanted to confirm that the variables were present when creating the credential to rule out that as being an issue. it looks like since they are local/hard coded, that would not have been a issue.