Registering DLL to get it working as a Credential Provider

Question

Hi all,

I'm developing a DLL purposed to work as a Credential Provider (CP) for Windows Vista. In accordance to some CP samples provided by microsoft, I'm trying to register it into the system by adding the following registry keys:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{9b02b9cf-6d3f-4ec5-a3c9-db0fdcdcff43}]
@="SABCredentialProvider"

[HKEY_CLASSES_ROOT\CLSID\{9b02b9cf-6d3f-4ec5-a3c9-db0fdcdcff43}]
@="SABCredentialProvider"

[HKEY_CLASSES_ROOT\CLSID\{9b02b9cf-6d3f-4ec5-a3c9-db0fdcdcff43}\InprocServer32]
@="SABCredentialProvider.dll"
"ThreadingModel"="Apartment"

where the hex string is the COM guid of my DLL.

For some reson this isn't working, and when I disable Windows default CP (normal user/password prompt) I cannot see my CP, neither I can log into the system. Any ideas why this may be not working? Is there anything else I'm missing?


PS: a link to some good documentation about CPs is also welcome, as the documentation I've found after hours of research doesn't seem sufficient at all to me.

--
Arturo

Answer 1

The registry data you provided looks fine.  As long as you imported the data just as you posted it, and you have a component called SABCredentialProvider.dll under %windir%\system32 (assuming you didn't override the default path under InprocServer32) and your DLL exposes the exact CLSID that the registry data specifies and you are exposing IClassFactory methods and a credential provider filter installed on your system isn't filtering it out ... then you should be good to go.

On your test system, start the Remote Desktop Client (mstsc.exe), attach to it with the debugger and set breakpoints on your implementations of QueryInterface() and CreateInstance() (located in Dll.cpp if your code is based on one of the MS samples).  Then attempt to establish an RDP connection to another Vista (or Server 2008) system (but not an XP system!).   This should cause your provider to be loaded. 

If your breakpoints don't get hit, then you need to determine which of the checks from the previous paragraph is the problem.  If they are hit, make sure QueryInterface() is returning a valid interface pointer, and step into CreateInstance() as it calls your implementation of Provider_CreateInstance() and constructs the provider.  If all of that succeeds, then see if your implementation of ICredentialProvider::SetUsageScenario() is called.  If it is, and you support CPUS_CREDUI, then you can continue debugging other methods.  If you don't support CPUS_CREDUI, then you'll need to set up remote debugging and take it from there.

Let us know how it goes,

-IAmHe

Answer 2

Thank you for your detailed answer, iamhe, I'm sure it'll help other readers to get their CPs working.

About my problem, it turned out to be something really simple (and annoying at the same time). It was just that one of the libraries I needed in order to execute my credential provider was not installed in the target system. Thus, LogonUI was unable to execute my CP. All the requirements iamhe mentions in his answer are met by my CP, and it's now running ok (I'm debugging it right now).

Just something to mention about the debugging: I'm using the Visual Studio remote debugger (msvsmon), and for me it does work if I debug from Visual Studio 2008 in Windows XP.

Answer 3

About my problem, it turned out to be something really simple (and annoying at the same time). It was just that one of the libraries I needed in order to execute my credential provider was not installed in the target system.

Ah, yes ... just as I suspected.  ;-)

Good find, I didn't think of that possibility.  How did you figure it out ... depends.exe maybe?  What were you missing, the VS runtime libraries?

Just something to mention about the debugging: I'm using the Visual Studio remote debugger (msvsmon), and for me it does work if I debug from Visual Studio 2008 in Windows XP.

Good to mention, that is also how I debug providers.  It was truly gratifying to find out that it worked, given that all of the documents and articles I could find when I first got started indicated that you had to use a kernel debugger!

Answer 4

Good find, I didn't think of that possibility.  How did you figure it out ... depends.exe maybe?  What were you missing, the VS runtime libraries?

Yep, old depends.exe helped me out -it always does. And yeah, good guess, the missing library was the debug C++ runtime library, msvcrtd.dll, which seems not to be present in Vista unless VS gets installed.