Bug: Invalid Credentials Exception since DVLS Update 2022.1.10.0

Implemented

Bug: Invalid Credentials Exception since DVLS Update 2022.1.10.0

avatar

Ive updated today to DVLS 2022.1.10.0 and now im not able anymore to authenticate via Powershell Module:
forum image

Global Var DSSessionToken is set but dont look like its a valid token:
forum image
forum image

The Username and Password set in Credential Manager are 100% correct. Login direct via Web is possible.
Report Log:
forum image

PS Module: 2021.6.4 - I also tried the current Version from GitHub.
PowerShell 7.2.1

Best Regards
Andreas

All Comments (11)

avatar

Hello Andreas,

I was able to replicate your issue with a custom user, DVLS 2022.1.10 and the DS PS module 2021.6.4.

I will open an internal ticket to the engineering team and report back their findings.

Best regards,

Richard Boisvert

avatar

Hello,

A new version was pushed in GitHub with the fix, it should be available in PowerShell Gallery soon.

https://github.com/Devolutions/devolutions-server/releases/tag/2022.1.10.0

Best regards,

Richard Boisvert

avatar

Im also having this issue.
Running DVLS version 2022.1.10.0
Powershell Module version 2022.1.10.0

VERBOSE: [Login] Beginning...
VERBOSE: GET https://{dvls-url}/api/server-information with 0-byte payload
VERBOSE: received 12863-byte response of content type application/json
VERBOSE: [New-CryptographicKey] Beginning...
VERBOSE: [New-CryptographicKey] Completed Successfully.
VERBOSE: [Encrypt-RSA] Beginning...
VERBOSE: [Convert-HexToBytes] Beginning...
VERBOSE: [Convert-HexToBytes] Completed Successfully.
VERBOSE: [Convert-HexToBytes] Beginning...
VERBOSE: [Convert-HexToBytes] Completed Successfully.
VERBOSE: [Encrypt-RSA] Completed Successfully.
VERBOSE: [New-AESService] Beginning...
VERBOSE: [Convert-HexToBytes] Beginning...
VERBOSE: [Convert-HexToBytes] Completed Successfully.
VERBOSE: [New-AESService] Completed Successfully.
VERBOSE: POST https://{dvls-url}/api/login/partial with 712-byte payload
VERBOSE: received 152-byte response of content type application/json
Exception: .\Devolutions.Server\2022.1.10.0\Public\Authentication\New-DSSession.ps1:116:17
Line |
 116 |                  throw $_.Exception.Message
     |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~
     | InvalidUserNameOrPasswordPleaseVerifyYourCredentials
avatar

Hello,

Just to be certain, are you using a custom (local) user? That error is usually when using a domain or O365 account.

I just tried it and it worked as expected with a custom user, but it was on Devolutions Server 2022.1.12 and PowerShell 7.2.3:

VERBOSE: [Login] Beginning...
VERBOSE: GET with 0-byte payload
VERBOSE: received 1095-byte response of content type application/json
VERBOSE: [New-CryptographicKey] Beginning...
VERBOSE: [New-CryptographicKey] Completed Successfully.
VERBOSE: [Encrypt-RSA] Beginning...
VERBOSE: [Convert-HexToBytes] Beginning...
VERBOSE: [Convert-HexToBytes] Completed Successfully.
VERBOSE: [Convert-HexToBytes] Beginning...
VERBOSE: [Convert-HexToBytes] Completed Successfully.
VERBOSE: [Encrypt-RSA] Completed Successfully.
VERBOSE: [New-AESService] Beginning...
VERBOSE: [Convert-HexToBytes] Beginning...
VERBOSE: [Convert-HexToBytes] Completed Successfully.
VERBOSE: [New-AESService] Completed Successfully.
VERBOSE: POST with 557-byte payload
VERBOSE: received 2954-byte response of content type application/json
VERBOSE: [New-DSSession] Successfully logged in to Devolutions Server


Best regards,

Richard Boisvert

avatar
Hello,

Just to be certain, are you using a custom (local) user? That error is usually when using a domain or O365 account.

I just tried it and it worked as expected with a custom user, but it was on Devolutions Server 2022.1.12 and PowerShell 7.2.3:
VERBOSE: [Login] Beginning...
VERBOSE: GET with 0-byte payload
VERBOSE: received 1095-byte response of content type application/json
VERBOSE: [New-CryptographicKey] Beginning...
VERBOSE: [New-CryptographicKey] Completed Successfully.
VERBOSE: [Encrypt-RSA] Beginning...
VERBOSE: [Convert-HexToBytes] Beginning...
VERBOSE: [Convert-HexToBytes] Completed Successfully.
VERBOSE: [Convert-HexToBytes] Beginning...
VERBOSE: [Convert-HexToBytes] Completed Successfully.
VERBOSE: [Encrypt-RSA] Completed Successfully.
VERBOSE: [New-AESService] Beginning...
VERBOSE: [Convert-HexToBytes] Beginning...
VERBOSE: [Convert-HexToBytes] Completed Successfully.
VERBOSE: [New-AESService] Completed Successfully.
VERBOSE: POST with 557-byte payload
VERBOSE: received 2954-byte response of content type application/json
VERBOSE: [New-DSSession] Successfully logged in to Devolutions Server
Best regards,


We are using application user, which I guess counts as a local user?
We have updated to 2022.1.12 but no difference.

This is the code I test with:

$DS_URL= 'https://{dvls-url}'
$appSecret = '{app-secret}' 
$appKey = '{app-id}' 


[securestring]$Password = ConvertTo-SecureString $appSecret -AsPlainText -Force
[pscredential]$Credential = New-Object System.Management.Automation.PSCredential ($appKey, $Password)
New-DSSession $Credential $DS_URL -AsApplication -Verbose


avatar

Hello,

I also tried with an application key and the code you provided, and it is working as expected:

forum image

Just to be sure, can you check the version of the module:
(get-module Devolutions.Server).Version
forum image

Best regards,

Richard Boisvert

avatar

Yep, using the same version as you
Just updated powershell to latest, but no difference.

forum image

avatar

Hello Jesper,

I did my test on a DVLS on the same local network as my machine. Is there anything specific in your environment? For example, a load balancer or a reverse proxy, a WAF, cloud hosting (AWS/Azure), etc.?

Also, could you try connecting, with the Powershell module, on the server hosting your DVLS, to exclude firewall issues?

Best regards,

Richard Boisvert

avatar

Hello Richard,

I have found the issue.
Versions before 2022.1.9 does not require custom user to be activated as authentication method for application user to work, now it does.
I would like to report this as an issue.

avatar

And yes, I confirmed it works like this in previous version.

avatar

Hello Jesper,

I was able to replicate your issue, if the custom user is not enabled, the authentication via the application key does not work.

I will open an internal ticket to the engineering team.

Best regards,

Richard Boisvert