When attempting to use remote desktop from a Windows 10 (21H2 19044.1566) box to an Ubuntu 22.04 LTS (fully patched), I receive the following error:
An authentication error has occurred.
The token supplied to the function is invalid.
Remote computer: {Computer name}
This is when attempting to RDP with an AD domain user, which I can confirm logs in successfully locally.
Verify the password in Settings->Share->Remote Desktop in Authentification section, maybe it's not the same as the one you use to connect in SSH or locally
Unsecuring the "Login" Keyring, as described in this answer has solved the issue for me.
Password and Keys application -> Right-click on Login keyring -> change the password to blank. This adds a security vulnerability but might be acceptable in some setups.
Related
I'm using git over ssh on a remote machine that is running Windows 10. When I try to do a git pull, I get the error message in the title after entering my credentials.
Fixed by installing the latest version of git credential manager on chocolatey (not sure if this is necessary) and switching my git credential store to dpapi.
See https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/credstores.md#dpapi-protected-files for instructions on how to do so.
This could be illustrated by GitCredentialManager/git-credential-manager issue 325
The error you're seeing is related to the way that Windows handles "logon sessions" and "credential sets".
GCM Core uses the Windows Credential Manager (wincred.h) to store credentials safely on Windows.
We interact with wincred via the Windows APIs: CredRead, CredWrite, CredDelete, and CredEnumerate.
The error being returned in your case here is ERROR_NO_SUCH_LOGON_SESSION (0x520) which means:
The logon session does not exist or there is no credential set associated with this logon session.
Network logon sessions do not have an associated credential set.
The key part here is in bold.
When you connect via SSH, the sshd daemon/Windows service is running as the NT AUTHORITY\NETWORK SERVICE account (most likely/by default), which creates network logon sessions when an SSH client connects.
From some searching online, one workaround posted is to change the account that sshd runs as to be your real user, which would then have an associated credential set. Your milage may vary here depending on setup.
If you try to use the built-in cmdkey command for interacting credentials stores in the Windows Credential Manager, you'll see similar errors or messages like "saved for this login only".
Upgrading to the latest version of GCM comes with:
With the latest GCM Core release (v2.0.567) there is support on Windows to use a different credential store other than the Windows Credential Manager that shouldn't have the same remote-session limitations.
You can read more about the different options here: https://aka.ms/gcmcore-credstores
The specific store that may help this SSH scenario is the DPAPI-protected file store.
Credentials are protected using Windows DPAPI encryption (based on your current user account) and are written to files on disk (configurable; defaults to %USERPROFILE%\.gcm\dpapi_store).
On my new Windows 10, as I am trying to install Jenkins, I encountered following prompt:
Since I don't know what local or domain user creds to enter, I keep on getting following error:
Error logging on DESKTOP-xxxx\user: The user name or password is incorrect
From reading the official doc, I am understanding that this is something new that Jenkins installer is doing for running as a Windows service, but where do I find these credentials on Windows?
Most of the applications when installed on Windows OS may want to run as a service using either the local system account or a specific account which needs specific permissions on the OS. Please use any local admin account which already there on the system where you are trying to install Jenkins. If the system is joined to a domain, prefer to use an domain account which has admin privileges on the system.
The worst advice to grand admin permissions for a single service.
You need to use local existing credentials from your windows system (if it's not connected to a domain) or a domain creds. Don't use admin creds for the installation.
I'm trying to connect my machine (MacOS) to a remote. I went on AWS and create a windows instance, I use the default security groups and downloaded the rdp file.
I open it with Microsoft Remote Destock and ends up with an error message:
Unable to connect to remote PC. Please verify Remote Desktop is enabled, the remote PC is turned on and available on the network, and then try again.
I tried to run the rdp file on a windows machine, I got the same error.
My question is: How do we set the security groups to open windows remotely.
Thanks
check your security group and make sure you have open RDP(3389)port.
Then you can generate your password by.
EC2 console --> Connect To Your Instance --> Get Password --> Choose Browse and navigate to the private key file --> Decrypt Password.
The console displays the default administrator password for the instance in the Connect To Your Instance dialog box.
If you want to generate Remote Desktop File or details information you can go throught below link. https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html
I have a Windows 2008R2 server in GCE that is behaving oddly (may be compromised). I can no longer access it via RDP. When I reboot the machine and look at the serial console, I see at the very bottom after the boot sequence, that something called Credentials Manager runs and appears to delete or change some username/password. I suspect that this is what is changing the RDP password. (see image attached). On a normally running Windows VM, I do not see this in the trace.
GCE Agent started.
Starting AddressManager
Starting CredentialsManager
Credentials have changed. Updating...
Changing username...
Deleting old user...
Username or password was updated successfully.```
I have tried resetting or adding a new password using the metadata windows-startup-script-cmd = net user but that does not seem to do anything.
What I get is an error message of the form:
Booting on date 05/05/2015 10:22:49
WARNING: Computer Name windows does not match Compute Engine Instance Name XXXXX.
Did you forget to run gcesysprep?
attributes/windows-startup-script-bat value is not set or metadata server is not reachable.
attributes/windows-startup-script-ps1 value is not set or metadata server is not reachable.
So the question is, how can I get into the machine to see what is happening? Is there a way that the GCE startup sequence could be changed to not call the credential manager to change the password or username?
What you could do is if you have a Gcloud SDK (https://cloud.google.com/compute/docs/gcloud-compute/) installed, you can run the following command while that instance is running:
gcloud compute instances decribe instance_name
This will provide all the information about the instance and you will see a section called MetaData which will display the users and the passwords. Then you can try to remote in and remove any credentials setup in the Credentials Manager located in Control Panel -> User Accounts.
I hope this give you access to your VM
I am sharing a directory on a ubuntu server over samba. When I mount the samba share with mac os x then it works perfectly fine. However, when I mount the samba share on windows and I enter the exact credentials as before, I get the error message:
\172.20.1.2\share is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. Multiple connections to a server or shared resource by the same user, using more than on user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.
I have totally no idea what went wrong. When I enter the credentials on windows I even excluded the domain by entering the username as \admin . Does anyone know what the problem is or what I can check to get further details about what the actual problem is?
The problem that somehow the windows machine already "cached" an old credential. After restarting the machine it works fine.