Azure-docs: CMDKEY: Credentials cannot be saved from this logon session.

[setht2]

When running this command:

PS C:\WINDOWS\system32> Invoke-Expression -Command "cmdkey /add:$([System.Uri]::new($storageAccount.Context.FileEndPoint
).Host) /user:AZURE\$($storageAccount.StorageAccountName) /pass:$($storageAccountKeys[0].Value)"

It fails and I receive:

CMDKEY: Credentials cannot be saved from this logon session.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: c12f1ea9-6446-be01-22fe-885fb945d22c
• Version Independent ID: 634f8ace-1a8c-6811-627b-fdfbdd1942a3
• Content: Use an Azure file share with Windows
• Content Source: articles/storage/files/storage-how-to-use-files-windows.md
• Service: storage
• GitHub Login: @RenaShahMSFT
• Microsoft Alias: renash

[AdamS-MSFT]

@setht2 Thanks for posting, quick question, was your PS session opened as an Admin by any chance?(right click on PS then run as Admin)

[setht2]

I tried both as Administrator and my account, with the same results.

I may have found a work-around that does not use CMDKEY but instead uses New-PSDrive, but the drive is not showing in File Explorer, even with -Persist.

[AdamS-MSFT]

Thanks for the info, I will assigned it to the author to check on the commands again.

[setht2]

Thanks, Adam. For what it's worth, the issue with persistence was related to the script to mount the file share being executed in PowerShell by a user different than the user attempting to access the share.

My original issue, with "Credentials cannot be saved from this logon session", persists, but I have found a work-around.

[setht2]

This definitely is not working (repeated error: "CMDKEY: Credentials cannot be saved from this logon session."), even with running PowerShell as admin, and we need to have the file share persisted between reboots for the user. Any help would be appreciated.

$resourceGroupName = "rmname"
$storageAccountName = "strgname"

$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName
$storageAccountKeys = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName

Invoke-Expression -Command "cmdkey /add:$([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) /user:AZURE\$($storageAccount.StorageAccountName) /pass:$($storageAccountKeys[0].Value)"

[wmgries]

Hi folks,

There are a few issues here that make it somewhat of a pain to work with mounting on Windows:

1. When logged in via a remote session (such as via PowerShell remoting or other command line remoting BUT not remote desktop), cmdkey will report the Credentials cannot be saved from this logon session issue. This is by [bad] design behavior in Windows. We've explored getting it changed/improved in a future version of Windows, but right now I have nothing to report.

1. cmdkey specifically requires the credential to be added to the user's context. In other words, when I add the storage account key to my storage account, I persist it for me, but not for other users on that PC - which is especially important for service account users, for which you cannot log into an interactive session (see issue 1).

2. When I mount a share as an administrator, it's not visible to me as a regular user in File Explorer. Shares must be mounted as regular users.

I've run through this example on a fresh Azure VM and it does in fact work with one exception - Invoke-Expression's multi-line command fails because of missing parentheses. This did at one point work, so it's unclear if I had the parentheses on my machine and copied it into the doc incorrectly, or if they were removed after by an (un)helpful contribution (I couldn't immediately find the source of the issue from git log). At any rate, I am restoring them in a PR to go out this afternoon.

Please confirm you are trying this via remote session, rather than remote desktop, and that it works via remote desktop. If you're having this issue with remote desktop, we can escalate to the Windows team to see why it's not working for you - this does work on a stock Azure VM.

Thanks,

Will Gries
Program Manager, Azure Files

[wmgries]

Haven't heard back, so I'm going to ask for this to be closed. Please feel free to comment on this thread, or send us an email at [email protected] if you have further questions here.

Thanks,

Will

please-close.

[setht2]

Thank you, Will, I hadn't had a chance to fully go through your comment. What we're trying to do is mount the file share on a Windows laptop that is part of our domain but not in Azure. From what I understand from your comment and other reading, these file shares aren't meant to be mountable anywhere other than on Azure VMs?

I figured out your points #2 and #3 by trial and error, seeing that same behavior, which I have no issue with. #1 may apply to us but again, this is a domain laptop, not an Azure VM.

For the record, this is running PowerShell on my laptop as my domain user (I've also tried running PowerShell as Administrator), attempting to mount the file share on the laptop, and I receive that error.

Thanks again for the help, Will.

[WatersJohn]

Posting in case this helps someone else in the future: Check the value of the following group policy setting; if it is set to enabled you will receive this message.

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Network access: Do not allow storage of passwords and credentials for network authentication

[david-drinn]

@WatersJohn What version of Windows were you using? That group policy was already Disabled, and I'm having this issue through a remote SSH session.