Error 1312 while using python keyring on Windows Server 2003

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?

Stearne

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.

Stearne

Hi Avihu, this is the closest thing I found for my problem. I'm using golang. When I run my go program in windows locally, it works fine. But when I ssh into cygwin server from other system and run the program it gives the exact issue that you are facing. Could you direct me in the right direction what might be the issue? I asked a questio here: serverfault.com/questions/884269/… – Jeromejeromy

Answer 2

I had a very similar issue, with the same error, to this one where my app that runs the python script was running as a service on the Windows server without any logged in user. Unfortunately the accepted answer now seems to be out of date and Win32CryptoKeyring no longer seems to exist as an option in keyring.

The solution I found was to install keyrings.alt, which hosts alternative keyring methods, and use the Windows.RegistryKeyring option. There isn't much documentation on how to use keyrings.alt, but the following seemed to work for me.

import keyring, keyrings.alt

keyring.backend.get_all_keyring()
keyring.set_keyring(keyrings.alt.Windows.RegistryKeyring())

For some reason it didn't seem to work without including the keyring.backend.get_all_keyring() statement, which lists all the available backend options. I don't know why.

Submultiple

This is such ancient history for me. I'd be surprised if the codebase that I was working on back then even exists, let alone even looks similar enough to this question to even have this answer applied to it. But thanks for the update to modern times :) – Stearne