Impersonate the security context of the Windows account

[tsatsulin]

When a Windows account user logs in, Win32-OpenSSH Server doesn't impersonate the security context of that Windows account throughout the user's SSH session.

From MSDN:

If you use these methods during impersonation, you may receive the following error: "Key not valid for use in specified state." This occurs because the DPAPI stores the key data in user profiles. If the profile is not loaded, DPAPI won’t be able to perform the decryption. To prevent this error, load the profile of the user you want to impersonate before calling either method. Using DPAPI with impersonation can incur significant complication and requires careful design choices.

My colleague @zaufi and I received this error "Key not valid for use in specified state." when we run nuget list. The error happened because nuget's config contains external repos and encrypted passwords. As a workaround we decided to used -storepasswordincleartext option, but hope this issue could be fixed in the near future.

Also, please note, to reproduce this issue you need to test it after boot, but before a login. Even if you logout, the user profile remains impersonated.

[manojampalam]

SSH remote sessions are run under the context of the client user. They are however network logon sessions and do not have user's credentials attached. DPAPI encryption and decryption only work with interactive logon sessions in general (or other specific logon sessions that have user's credentials attached), since these APIs actually use user's password to do the encryption and decryption.

User profile is guaranteed to be loaded for the duration of the session. I dont think the issue you are running into is due to profiles (rather its becuase of the nature of remote logon session).

[tsatsulin]

Hi Manoj,

Thank you for quick and detailed answer.

They are however network logon sessions and do not have user's credentials attached.

As I can see, they don't need to have it attached. From MSDN:

DPAPI initially generates a strong key called a MasterKey, which is protected by the user's password. DPAPI uses a standard cryptographic process called Password-Based Key Derivation, described in PKCS #5, to generate a key from the password. This password-derived key is then used with Triple-DES to encrypt the MasterKey, which is finally stored in the user's profile directory.

User profile is guaranteed to be loaded for the duration of the session.

Unfortunately, I have not found the place in the code where this happens. Could you please point me to the code?

Also, searching for "impersonation" term I have found the function LoadUserProfile and in the remarks I see:

When a user logs on interactively, the system automatically loads the user's profile. If a service or an application impersonates a user, the system does not load the user's profile. Therefore, the service or application should load the user's profile with LoadUserProfile.

[manojampalam]

User profile is loaded in ssh-agent (the Windows version is Windows specific. Load up the solution in Visual Studio and search for "LoadUserProfile"

[tsatsulin]

Found. Thank you. I will check how it works and write back. Please do not close this issue.

[cbhacking]

Two questions:

1. If the user connects over SSH using password auth, does this unlock DPAPI/EFS/etc. in the remote session?
2. Would it be possible to add a way to pass the password (for DPAPI, etc.) over public key auth session? Most of the time I'm using public key auth I don't want my password on the wire in any form, but given that Windows actually uses it a fair bit, a remote login that doesn't support unlocking stuff that requires the user's password is a lot less useful than one that does.

[manojampalam]

For (1) Yes, with password auth, remote session has user creds. So DPAPI works.

For (2) you will need to pass password explicitly for each operation needing authentication. Ex "net use"

[challarao]

@manojampalam Hello Manoj,

This issue seems to be related to an issue I am facing. Correct me if I'm wrong. If I logon via SSH with a user that is not the user specified in Log On tab of sshd windows service, and if I try to invoke cmdkey to list the Credential Manager keys, it would return empty list. Do you think it's due to network logon as well. But note that if I use the same user that is specified in Log On tab, it would work fine.

Thank you

[manojampalam]

@challarao I assume Credential manager would be locked using user's credentials. So if you login via password auth, you should be able to access it.

As a security measure, you should run sshd only under its service account.