[Bug] `acquire_token_silent_with_error` returns `None` with WSL broker

[jiasli]

Describe the bug
acquire_token_silent_with_error returns None with WSL broker (#766).

To Reproduce
WSL version:

> wsl --version
WSL version: 2.4.13.0
Kernel version: 5.15.167.4-1
WSLg version: 1.0.65
MSRDC version: 1.2.5716
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.3775

The initial acquire_token_interactive with organizations can return the access token as expected. However, when calling acquire_token_silent_with_error with a tenant ID, including home tenant (Microsoft tenant 72f988bf-86f1-41af-91ab-2d7cd011db47), the result is None.

Expected behavior
acquire_token_silent_with_error should work with a tenant ID.

What you see instead
acquire_token_silent_with_error returns None.

The MSAL Python version you are using
Latest dev branch.

Additional context
Add any other context about the problem here.

[rayluo]

CC Xiang Yan (@xiangyan99) for awareness

[DharshanBJ]

Jiashuo Li (@jiasli), this issue is likely because the keyring is not unlocked due to which msal is unable to fetch the token from the keyring.

Identity Auth stack on Linux relies on Keyring/secret service APIs as a secure storage for managing user authentication artifacts. On WLS, Keyring needs to be unlocked by the user before we can access it.
These are the instructions on how to unlock keyring on headless devices:
a. Start a D-Bus session, e.g. run dbus-run-session -- sh and run the following commands inside that shell.
b. Run gnome-keyring-daemon with --unlock option. Unlock options reads a password from stdin, and use it to unlock the login keyring or create it if the login keyring does not exist.
When that command is started, enter a password into stdin and press Ctrl+D (end of data). After that, the daemon will fork into the background (use --foreground option to block).

For a complete set of instructions see: [Using Keyring on headless Linux systems](https://github.com/jaraco/keyring#using-keyring-on-headless-linux-systems)

So for an application running in WSL to interact with MSAL and access the keyring, you must run the application within the same session where the GNOME Keyring Daemon is unlocked. Keyring access will only work if the application runs inside that session.

This is a known limitation with WSL, and we are working with them to make this seamless for the calling apps.

[jiasli]

dbus-run-session -- sh doesn't seem to work well with Python's virtual virtual environment and shows gibberish:

user2@DESKTOP-A79F1:~$ . ~/env/bin/activate
(env) user2@DESKTOP-A79F1:~$ dbus-run-session -- sh
(env) \[\e]0;\u@\h: \w\a\]\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]$

But luckily this doesn't affect command execution. It is also normal without a virtual environment.

[jiasli]

gnome-keyring-daemon is not installed on WSL by default and requires manual installation:

$ gnome-keyring-daemon --unlock
Command 'gnome-keyring-daemon' not found, but can be installed with:
sudo apt install gnome-keyring

After running

sudo apt install gnome-keyring

then

dbus-run-session -- sh
gnome-keyring-daemon --unlock

broker starts to work.

I noticed I need to press Ctrl+D twice. This is also mentioned by

• https://www.ibm.com/docs/en/z-chatops/1.1.3.x?topic=chatops-configuring-encryption-key-store
• https://docs.zowe.org/stable/user-guide/cli-configure-scs-on-headless-linux-os/
• https://knowledge.broadcom.com/external/article/239323/brightside-scs-plugin-unable-to-unlock-k.html

and explained by

• https://stackoverflow.com/questions/1516122/how-to-capture-controld-signal
• https://unix.stackexchange.com/questions/701317/when-using-cat-to-create-file-i-have-to-type-ctrld-twice-to-finish-the-input
• https://stackoverflow.com/questions/7369170/why-do-i-have-to-type-ctrl-d-twice
• https://stackoverflow.com/questions/2162914/why-do-i-have-to-press-ctrld-twice-to-close-stdin

For acquire_token_silent_with_error, instead of returning None, it should tell the user the required gnome-keyring-daemon is missing.

There should be document clearly describing the prerequisites to use broker on WSL, instead of letting users to troubleshoot by themselves. The document should also describe how to reset the keyring if the password is forgotten, such as https://askubuntu.com/questions/65281/how-to-recover-reset-forgotten-gnome-keyring-password

[DharshanBJ]

We have updated the documention that explains the steps to unlock the keyring - https://learn.microsoft.com/en-us/entra/msal/python/advanced/linux-broker-py-wsl?tabs=ubuntudep
Users can use Seahorse (a GNOME application for managing encryption keys and passwords) to manage the keyring contents through a Graphical User Interface (GUI) which gives a better UX.