Credential Providers cannot make an authentication decision. They only collect credentials. The approach I took in “Aucun” is that the Gina actually makes the authentication decision. That will not work under the new Credential provider architecture.

When I started looking to port my Gina to a Credential Provider, I first though of saving the initial credentials (when the first user logs on), then check any other user’s credential in my own Credential Provider, and if all is good, replay the initial credentials.

That bothered on many grounds :

• There will be a unlock event logged to the initial user, although that user never unlocked the workstation
• I don’t like saving passwords, even to encrypted memory
• That architecture didn’t look like something that would last

Looking deeper into the Credential Provider interface, I saw that there is one decision a Credential Provider can make. It can select what Authentication Package will honor the logon request (or unlock request, in my case). That takes place in my (your) ICredentialProviderCredential::GetSerialisation, by setting the ulAuthenticationPackage field of the CREDENTIAL_PROVIDER_CREDENTIAL_SERIALIZATION structure.

So I believe the right way of doing this is to have two components :

1. An authentication package that implements the unlock policy (any user can unlock, depending on group membership).
2. A credential provider that collects credentials (and while you’re at it, the session you want to unlock) and instruct winlogon to forward them the “unlock” authentication package.

That architecture fixes all three points above. And as a bonus, I can greatly simplify my existing Gina by merely collecting the credentials and forward them to the same authentication package. No need to hook dialog procedures and sending magic, reversed engineered constants to winlogon. In short, instead of making the Credential Provider look like a Gina, I make the Gina behave like a Credential Provider.

Authentication packages are the same under Vista and XP, that’s a good thing. But to debug them, you need the scary kernel remote debugging tools. You also need to reboot every time you mess up. But I have a working authentication package from CVS NT code source, and another called YPAuth (YP means yellow pages, the old name of NIS). None of them support the unlock scenario, though…

Stay tuned !

The trick is to subtract 4 from the Capabilities in the registry. Not easy, but it can be done. The only thing is that it keeps coming back after every boot ! And it looks like the value cannot be edited under Vista. Here is how to fix it for good.

What has to be done (but doesn’t work)

Find the drive that shows up in the safely remove hardware icon in your registry. It will be somewhere under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\. My DVD drive was here :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\CdRomHL-DT-ST_DVDRAM_GMA4082Nj_______________PM01____

There is a numerical an alphanumerical key under that with a DWORD Capabilities value.

It is a bit field. The bit 0010 (4 in decimal) is the REMOVABLE bit. Clear it by subtracting 4 from the value you have. The value I had was 6, so now I am down to 2.

If you try to do that, you will get an access denied. That’s ok, we will get around that. For now, right click on the key name and copy it (the key named 5&3392c8c4&0&0.0.0 in my example).

Same idea, that works manually under Vista

You need to have the TCB privileged enabled to modify that registry key. Running regedit as an administrator (or elevated, if you have UAC) will not work. You can fix the value with this command line :

psexec -s reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\CdRomHL-DT-ST_DVDRAM_GMA4082Nj_______________PM01____\5&3392c8c4&0&0.0.0" /v Capabilities /t REG_DWORD /d 2 /f

You will have to replace the key name with what you found in your registry. Running psexec -r regedit might work, but who wants to do that every time the computer boots ?

Permanent fix

I hardly ever run as an administrator, so putting the above command in a script was out of the question. The solution was to create a Task using Windows Task Scheduler. I set it to run at startup, under the SYSTEM account. Don’t forget the /f (force) flag, or else the job will appear to hang, waiting a confirmation from you.

Create a new task. In the “General” tab, click Change User or Group and enter “SYSTEM” . Trigger on startup and enter the same command as above, but without psexec -s. Your task is running reg.exe, with everything right of that (in the command line, earlier) as optional arguments.

Good luck and HTH !

I found a detailed explanation of the MSCASH format. Here is how you make your own MSCASH hashes to do close to reality benchmarks of your favourite password cracking tool.

The format is MD4(MD4(password) + username). password and username are in Unicode. In the explanation linked above, we have the classical "user" and "password" combination. Using notepad, type your password. Save the file using Unicode format. The first two bytes of the file will be FF and EF, a flag called the byte order mark (BOM). Delete them using an hexadecimal editor. It should look like this :

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  70 00 61 00 73 00 73 00 77 00 6F 00 72 00 64 00  p.a.s.s.w.o.r.d.

Now calculate the first hash with openssl, with a binary output :

openssl dgst -md4 -binary password.unicode.txt > md4.password

Type and save your user name in Unicode format, remove the BOM, and concatenate the Unicode user name to the first hash.

copy /b md4.password + user.unicode.txt md4.password.user

The file should look like this (the first 16 bytes is the md4 hash of the password) :

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  88 46 F7 EA EE 8F B1 17 AD 06 BD D8 30 B7 58 6C  ˆF÷êî.±...½Ø0·Xl
00000010  75 00 73 00 65 00 72 00                          u.s.e.r.

Now just hash that last file, again with openssl :

openssl dgst -md4 md4.password.user
MD4(md4.password.user)= 2d9f0b052932ad18b87f315641921cda

You can now use that MSCASH hash for your benchmarks. I hope you find it usefull. I might write a program in C to automate this, If I see good traffic on this post. Spread the word !

• Vista Home Premium and Vista Business support (same binary works on XP and Vista)
• Better error handling on platforms that don’t support IUserNotification
• Option to specify pop-up delay in seconds (/d 5 or /d 5000 will give you 5 seconds)

I updated the main project page. There are a couple of typos and the email link is gone. I will fix that sometimes this week. Click on the bitmap here or on the project page to download.

Enjoy !

• Allow force log off without being a member of the administrator group
• Allow an arbitrary group to be excluded from this GINA unlock policy
• Show a notice that a custom GINA is in place

I also put up a permanent page for the project. It has better documentation and fancy graphics. Enjoy !

A friend of mine wanted a special group of users to be able to unlock a workstation without losing any data. Putting those uses in the administrator groups was not a solution, because the default behaviour of Windows was to close or terminate every process and give the administrator a brand new session. Fast user switching added some tricks, but in the end there was no way to recover an open document with modifications in it from a locked Windows workstation.

The project has its own page now. If you are a computer historian, read on for the original first release.

He asked me if I could write a screen saver to do this, but the answer was a little deeper under the hood, and a lot more fun. I wrote a replacement Graphical Identification and Authentication DLL (GINA DLL) that hooks the standard Microsoft Windows Gina DLL of Windows XP and Windows Server 2003. It also supports Terminal services sessions. It allows you grant members of a group (any group) to unlock any user’s session. No need to be an administrator. Any user can unlock now (Aucun).

Microsoft replaced GINA DLLs with credentials providers (ICredentialProvider), somewhat like the Solaris pluggable authentication modules PAM. This Gina DLL will never work in Vista, by design.

Turns out it is pretty easy. You can get the source code and a compiled binary here. I recommend that you don’t trust me with your password and work with the source. Anonymous Subversion access with this command

svn co http://src.paralint.com/aucun/trunk aucun

I started with the Gina Hook sample from the SDK, and added support for terminal services. Then I stripped away all the unnecessary hooks and updated the dialog detection code. A few registry calls later and some basic group membership checking later was all that was needed.

To allow any user from any given group to unlock a Windows session, you have to:

1. Hook every function of the regular Gina, msgina.dll
2. Export every function yourself, forwarding them all to msgina.dll as is except for WlxNegotiate and WlxInitialize
3. In WlxInitialize, hook the Windows provided function WlxDialogBoxParam (so msgina.dll will call your DLL when it creates a dialog box)
4. In your version of WlxDialogBoxParam, let everything go through except requests to create the unlock dialog
5. Hook the DLGPROC and wait for WM_COMMAND with wParam == IDOK
6. Check the user’s password (LogonUser with LOGON32_LOGON_UNLOCK)
   • If it doesn’t match, let the call go through the regular GINA
   • If it matches, and the user is part of the group you want to be able to unlock (CheckTokenMembership), call EndDialog with IDOK
   • It it matches and the user is not in the group you want to be able to unlock, let the regular GINA handle it

That’s about it. The third bullet of item 6 is actually what will happen most of time. The same user that locked its station comes back and enters a password that matches, but that regular user is not part of the unlock group. MSGINA.DLL handles it and unlock the session as usual. (UPDATED january 8th 2008 ->) If you audit logon events, succesfull or failed, they will be logged under the name of the person unlocking the session, not the original user. It is a deterrent measure only, it will not give you non-repudiation of actions made after the session was unlocked.

I insists there is no need for the users to be members of the administrators group for this to work. With my implementation, you merely set a registry key with the name of the group you want to use. Add any user(s) or group(s) to this group.

HKEY_LOCAL_MACHINE\SOFTWARE\Paralint.com\Aucun"GroupName"="paralint.com\DG_SESSION_UNLOCKERS"

I might add a blacklist feature, so that members of the the administrative group can never be unlocked. It is not hard to do. If I see interest in this project, I write it happen.

The code is all plain old, good old C. Function pointers, hooked procedures. All the fun stuff .Net hides from you Remember: Gina were introduced in Windows NT 3.51, some 15 years ago. And yes, I was already a Windows programmer back then…

But I don’t run Vista like that: I run it the hard way. I am a regular user, and in the rare cases I need it, I switch over to another account that has administrative privileges. I disabled user account control (UAC) alltogether.

If you’re like me, try this 2 step trick to render you Vista slow or completely DOS (denial of service) depending on CPU and memory.

Save you work before you try this, you might have to reboot…

Bring up the task manager with CTRL-SHIFT-ESC. Click the “Resource Monitor”. Watch your screen flicker as your CPU goes up and your battery goes down…

No mapping between account names and security IDs was done

It would have happened with a Windows Station handle (HWINSTA) also. It turns out there is a sensible and documented reason for that. But since I had to found out the hard (as in fun) way, I am posting it here.

If you are familiar with the ways SID (security identifiers) are handed out when you logon, here is the reason straight up :

The SID associated with desktops and window stations is not the SID of the logged on user, but the logon SID, a SID generated at logon time that identifies exactly and only this logon session. No account name is mapped to this transient SID, hence the error message.

Still confused ? Read on.

Security descriptor crash course

Consider this : you open a remote desktop connection (terminal server) to a server and log in. You have a logon session on that machine. Keeping that session alive, you walk up to the server and log-in again, interactively. You now have 2 logon sessions on that machine. How does windows prevents one session from interfering with the other?

Well, security is always about assigning security descriptor (SECURITY_DESCRIPTOR) to things. A security descriptor is a discretionary access control list (DACL) made up of access control entries. Each ACE is a combination of allowed or denied access rights for a SID. A System Access Control list (SACL) that controls auditing and a few flags are also present, but it doesn’t matter to us now. So each desktop and window station (and any other object for that matter) are assigned something like this :

So we have a security descriptor, what will we use to authenticate against ? Our process or thread token, of course.

You are your logon session (any of them)

A token is like a conceptual pointer to a logon session. That logon session contains a unique logon identifier (LUID), the users SID and another SID, generated on the fly, that uniquely identifies a particular logon session. Here is a schematic view of the logon sessions and their SID:

You can see that the user SID is the same in the two logon sessions, but the Logon SID is different. Only the User SID is mapped to the principal (Alice in this example).

Keith Brown has a tool that lets view and change the security descriptor of the current window station and desktop. Running this tool (in the logon session with logon SID S-1-5-5-0-218443) shows this:

To prevent one window station from interfering with the other, Windows uses the granularity of the security API to its advantage (who wouldn’t?). Processes and threads from each logon have a token pointing back to the logon session they were started from. The desktop and window station are assigned a security descriptor that doesn’t grant or deny any rights to the users SID. Rights are granted to the logon SID.

What about my 0×534 error code?

For a reason I don’t really understand, the logon SID is not granted any name. When you crawl you way from a HDESK or (HWINSTA) handle, using GetUserObjectInformation and LookupAccountName, you will get error 0×534. It says "No mapping between account names and security IDs was done" because there never was a mapping of the logon SID with a name to begin with!

If you check you program with SysInternals (now Microsoft’s) Process Monitor, you’ll find an error saying”Bad Impersonation”.

LoadLibrary returns NULL and a call to GetLastError() says “Either a required impersonation level was not provided, or the provided impersonation level is invalid”.

If you just specify a filename, LoadLibrary will look in the current directory only. If supply a full path to the DLL, LoadLibrary will find it but the CreateFile will fail with Bad Impersonation.

I am still baffled by this behavior. I will keep looking into it. Meanwhile, here is a simple program that reproduces the problem.

BadImpersonation.cpp

You can get the full project using anonymous subversion :

svn co http://src.paralint.com/spikes/badimpersonation BadImpersonation

Good luck !