Skip to content

How to debug a Credential Provider locally

Here is a quick and easy way to debug a Credential Provider running on your development machine, without needing to set up a kernel debugging session with two computers. Before you go down this road, let me tell you a little bit about LogonUI.exe behavior (as seen on Windows 7 ultimate SP1 64 bits) set to require CTRL-ALT-DEL to log on.

  • Every time you type CTRL-ATL-DEL, a new LogonUI process is launched.
  • LogonUI will try to load any registered Credential Providers COM objects.
  • You can run any process on the secure desktop

With that knowledge, it is easy to set up a debugging session for your Credential Provider, right on your development machine. Before I continue, be aware that it might affect the stability of your computer temporarily, as the following illustration shows.

6015610

(Continued)

Unlocking another user’s session using Credential Providers

I have been working a little bit lately on a Credential Provider port of my custom GINA. I did some tests, I poked around the API and I whipped together something I could load and play with. The route I first thought of taking is still the right one, but I ran into some unexpected problems.

Microsoft new architecture is better, but the separation it enforces makes it hard to play tricks with the security policy. First, there are no shortcuts with Credential Providers. The documentation is formal :

CredentialProviders are not enforcement mechanisms. They are used to gather and serialize credentials. The Local Authority and Authentication Packages enforce security.

So we have to use an authentication package with the credential provider. Nothing that we didn’t see coming. I have played with authentication packages before, it just a matter of writing one.

Second, LogonUI will not kill another user’s session. I am able to get a credential provider tile on the unlock screen, logon with administrator credentials, but then I get this error message :

This computer is locked. Only the logged on user can unlock the computer.

Which makes some sense: why kill (or unlock) a user’s session if you can just start a new session next to it ? Unfortunatly, it does not help the most common use case my custom GINA users need to solve: many users need to access a single application running in a single session.

But I haven’t given up yet.

I tested on Windows 7 Ultimate 64bits, with or without fast user switching. If you ever able to unlock another user’s session, write a line in the comments. I would love to hear about it.

 

Can your GINA do this ? (running any process on the secure desktop)

I get asked a lot of questions about my custom Gina. Most of them come from people who want to write a custom Gina themselves to do … whatever.

A custom Gina runs in Winlogon’s process. It runs under the SYSTEM account, in the TCB… In short it can do pretty much anything. But some things just can’t be done, no matter what rights you have.

Fortunately, there is an easy way to tell if a GINA can do what you need it to do, without having to write a single line of code.

(Continued)