Question

I am writing a Windows Service in python and I am using the keyring module to safely store credentials that I need to use regularly and persistently. This means that keyring stores the passwords using the local system user credentials.

All I do is use the 2 basic keyring functions: get_password(SERVICE_NAME, username, password) and
set_password(SERVICE_NAME, username). I don’t preconfigure keyring as I understood it and saw that it configures its backend automatically.

When I run this on Windows Server 2008 and above everything works smoothly. But when I run this on Windows Server 2003, I get this nasty error:

error: (1312, 'CredWrite', 'A specified logon session does not exist. It may already have been terminated.')

I assume it has something to do with the logon session of the local system user that is used to run my service, though it is peculiar since I understood it’s a form of ultra-admin-super-user that’s supposed to have permissions to do anything it wants in the system. But when I change the logon credentials of the user to the local Administrator, everything works smoothly.

Is there something I need to change in the configuration of my service for this to work? Or change the security policies of the local system user? Or should I ask users to run this service with the local administrator credentials?

Answer 1

It appears that there is a limitation on the Local System user in Windows Server 2003 that it does not have access to the Windows mechanism of saving credentials also known as the Credentials Vault.

keyring’s default backend for Windows is to use this built-in Windows Vault mechanism, and that’s what creates that’s what triggers this exception from Windows.

The solution to this problem is to use a different keyring backend called Win32CryptoKeyring likes so:

keyring.set_keyring(keyring.backend.Win32CryptoKeyring())

This backend uses the Win32 Cryptographic API to securely save credentials, so security-wise it is as secure as using the Windows Vault mechanism. The difference is only the location the credentials are saved to. I’m not sure where the credentials are saved, but that has proved irrelevant to my case.

It is important to note again that this bug only occurs with the combination of using the Windows Vault from the Local System user under Windows Server 2003. On newer Windows versions this works perfectly fine and with other user on Windows Server 2003 it also works perfectly fine.

Using the Win32CryptoKeyring backend on newer versions of Windows also works perfectly fine if you want to be cross-platforms without using more than one secure mechanism for saving credentials in your code.