Windows preventing reg query on HKLM; returns HKCU instead

I'm using ActivePython 2.5 to read the registry for entries that pGina makes. Specifically, the entries concerning which GIDs are allowed on the computer. This information can periodically change for each computer as edited through pGina, so I want my Python script to be able to check these values each time.

Easy enough. The following Windows command will get that information for me:

reg query HKLM\Software\pGina\ldapauth\

...except when I run it with Python, I get this:

>>> import subprocess
>>> command = 'reg query HKLM\Software\pGina\ldapauth'
>>> ldapauth = subprocess.Popen(command, shell=False, stdout=subprocess.PIPE).communicate()[0]
ERROR: The system was unable to find the specified registry key or value.

So when I run 'reg query HKLM\Software' through Python, it spits out a list of the keys and values under HK CU\Software, rather than HKL开发者_StackOverflow中文版M.

I'm running Python as Administrator (confirmed by using getpass.getuser()) and when I run the same command from a batch script, I get the correct listing under HKLM. However, when I call the batch script from Python, back to the ole' HKCU results.

So, I'm a bit stuck. Does anyone have any insight?

EDIT: As detailed later, I am running Windows 7 64-bit and I have tried the _winreg methods, including the optional 4th "sam" argument in OpenKey.

Use winreg. (winreg.OpenKey and winreg.Query*). Way faster, no need to thunk out to running a shell command, and it will even return you tricky registry value types like BINARY as well, all in an OO way.

#import _winreg as winreg # the 'correct' idiom for importing
from _winreg import *

with OpenKey(HKEY_LOCAL_MACHINE,'Software\pGina\ldapauth') as key:
    ... do something with QueryValue(key[,...])

winreg does the job fine, although the interface is pretty quirky, since the underlying Windows interface was. You might well like to write a wrapper for the lookup call, esp. if like me you write a generator to get recursion and enumeration of subkeys, pattern-matching to key-names, restrict search to certain allowable registry values etc. etc.

So I still haven't found a solution to the root cause in my case. I can, however, work around it. A script run by SYSTEM upon every login will now export the key(s) in question to a text file which can easily be parsed.