[Bug] MSAL storage doesn't work on Linux system with XFCE desktop

Logs and network traces Without logs or traces, it is unlikely that the team can investigate your issue. Capturing logs and network traces is described in Logging wiki.

Which version of MSAL.NET are you using?

<PackageReference Include="Microsoft.Identity.Client" Version="4.46.2" />
<PackageReference Include="Microsoft.Identity.Client.Extensions.Msal" Version="2.23.0" />

Platform

PS /home/Friday> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.2.7
PSEdition                      Core
GitCommitId                    7.2.7
OS                             Linux 5.4.0-1095-azure #101~18.04.1-Ubuntu SMP Wed Oct 26 21:14:54 UTC 2022
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS /home/Friday> dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.402
 Commit:    6862418796

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /usr/share/dotnet/sdk/6.0.402/

global.json file:
  Not found

Host:
  Version:      6.0.10
  Architecture: x64
  Commit:       5a400c212a

.NET SDKs installed:
  2.1.818 [/usr/share/dotnet/sdk]
  3.1.424 [/usr/share/dotnet/sdk]
  5.0.408 [/usr/share/dotnet/sdk]
  6.0.402 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.30 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.30 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.30 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.17 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.10 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.30 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.30 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.17 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.10 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Download .NET:
  https://aka.ms/dotnet-download

Learn about .NET Runtimes and SDKs:
  https://aka.ms/dotnet/runtimes-sdk-info

What authentication flow has the issue? All the flows use token cache

Other?

Is this a new or existing app? b. The app is in production, I haven’t upgraded MSAL, but started seeing this issue.

Repro

• Login a Linux machine via VNC with keyring installed

gnome-keyring is already the newest version (3.28.0.2-1ubuntu1.18.04.1).

• and XFCE desktop configured

$ echo $XDG_CURRENT_DESKTOP 
XFCE

• In powershell, run

Import-Module Az.Account

Expected behavior Import-Module Az.Accounts sucessfully

Actual behavior Error message ** Message: 05:05:09.096: Remote error from secret service: org.freedesktop.DBus.Error.UnknownMethod: No such interface ‘org.freedesktop.Secret.Collection’ on object at path /org/freedesktop/secrets/collection/login

Possible solution

Additional context / logs / screenshots / links to code

Add any other context about the problem here, such as logs and screenshots, and even links to code.

[msJinLei]

@rayluo @bgavrilMS Its works! Thanks. Shall I close the bug?

[msJinLei]

Actual behavior Error message ** Message: 05:05:09.096: Remote error from secret service: org.freedesktop.DBus.Error.UnknownMethod: No such interface ‘org.freedesktop.Secret.Collection’ on object at path /org/freedesktop/secrets/collection/login

Hi @msJinLei - do you know Azure CLI supports this? I wonder if MSAL py has the same issue or not?

If it failed with a DBus error, the keyring service is likely not up and running. And then AzureCLI/MsalPython would likely also fail with the same error. It doesn’t harm if @msJinLei can try Azure CLI and confirm it. (Alternatively, if you do not have Azure CLI readily available, you can try pip install msal-extensions and then download and run this sample.)

The cause might be that @msJinLei was using that Linux box remotely via VNC. Remote session tends to have the keyring disabled. There might be a way to manually start the keyring in a headless session, by your mileage may vary.

@rayluo Thanks, I will try the method you propose!