Contents=

This = code and information is provided "as is" without warranty of any kind, eit= her expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.<= /p>

Infor= mation in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, produc= ts, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organizati= on, product, domain name, e-mail address, logo, person, place, or event is inte= nded or should be inferred. Comply= ing with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introdu= ced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. <= o:p>

Micro= soft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document d= oes not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Micro= soft, Windows Vista, Windows XP, and Visual Studio are either registered trademar= ks or trademarks of Microsoft Corporation in the United States and/or other countries.

Introduction

In th= is document, we’ll take a look at some custom Windows Vista credential provider samples. Specifically, we’ll cover the following topics:

1. Understanding the base SampleCredentialProvider codebase.

2. Common tasks for extending the b= ase SampleCredentialProvider codebase.

3. SampleAllControlsCredentialProvi= der, which exposes each possible UI control.

4. SampleCredentialFilter, which de= monstrates the ICredentialProviderFilter interface.

5. SampleCredUICredentialProvider, = which supports CredUI.

6. SampleHardwareEventCredentialPro= vider, which supports asynchronous events.

7. SampleWrapExistingCredentialProv= ider, which wraps the default username/password credential provider in Windows Vi= sta.

Re= lease Notes

This = is the fourth release of the samples. The f= irst release targeted the February CTP. The second release targeted Beta2 and added additional samples. The third release updates those sa= mples for Vista RTM. This fourth re= lease updates the samples for Windows 7.

Sa= mpleCredentialProvider

Out o= f the box, SampleCredentialProvider provides a DLL project that exposes the two C= OM interfaces required to develop a credential provider: ICredentialProvider a= nd ICredentialProviderCredential. ICredentialProvider exposes the functionalit= y to enumerate available credentials, and ICredentialProviderCredential exposes = the functionality required for each specific credential during the authenticati= on process.

The SampleCredentialProvider Codebase=

The SampleCredentialProvider project provides a working baseline credential provider. This sample is hardcoded to expose two accounts: Administrator and Guest. The following screensh= ot shows what this might look like on a domain joined machine.

3Ddoc

Project Structure

The SampleCredentialProvider project includes a small set of files, each with t= heir own purpose:

File[s]<= /p>	Purpose<= /p>
com= mon.h	Des= cribes the UI and layout of the credentials. Edit this file to change the number= and type of UI elements in each credential tile.
CSa= mpleCredential.h/.cpp	Def= ines the behavior of a credential tile. Edit these files to change the way a tile responds to user input.
CSa= mpleProvider.h/.cpp	Def= ines the behavior of the credential provider, which typically manages one or more CSampleCredentials. Edit this file to change the way credentials are enumerated.
dll= .h/.cpp, samplecredentialprovider.def	Ful= fills baseline support for COM server and DLL requirements. You shouldn’t need to edit these files.
gui= d.h/.cpp	Def= ines the provider’s GUID. You’ll need to edit guid.h to reference your unique GUID.
hel= pers.h/.cpp	Pro= vides utility methods for working with UNICODE strings and auth packages. You shouldn’t need to edit these files.
Reg= ister.reg, Unregister.reg	Reg= isters and unregisters the sample credential provider, respectively. You’ll ne= ed to edit these files to use the GUID from guid.h wherever a GUID appears. You’ll also need to edit the Register.reg file to reflect the name = of your object (the first two registry keys) and the name of the DLL (the th= ird registry key).
res= ource.h, resources.rc	Man= ages provider resources, such as the tile image. Edit these files if you want = to add more resources, such as images, to the credential provider.
til= eimage.bmp	The= image to display on the credential tile. Edit this file (or add different image= s) to change the image that appears in the tile.

These= files are divided between the Helpers\ subfolder, which includes code common to e= ach sample, and the SampleXxx\ subfolders, which are specific to each sample.

Co= mmon Tasks For Extending SampleCredentialProvider

Since SampleCredentialProvider provides a great baseline for developing custom providers, it is recommended that you customize it to meet your needs, rath= er than starting from scratch. The following steps will walk you through the process of customizing the SampleCredentialProvider project that is common = to all extensions.

We= 217;ll use “MyCredentialProvider” as the new project name, so be sure = to change it to reflect the name you want to use. We’re also not going to rename any of the folders or files to reflect the name unless it is require= d to build successfully, so this may be something you choose to do once you̵= 7;re comfortable with the codebase.

Pleas= e note that these samples are intended to be run against the RTM version of Window= s 7. They should be compiled against th= e RTM version of the Windows SDK.

1. Set up Visual Studio 2008 in Too= ls | Options to use the executables, includes, and libs from the SDK instead of = the ones shipped with VS. For mor= e info on how to do this, see ReleaseNotes.Htm in the root of the SDK directory.

2. In the SampleCredentialProvider folder, double-click the SampleCredentialProvider.sln to open it in Visual Studio 2005.

3. In the Solution Explorer, right-click the SampleCredentialProvider project node and select Rename. Change the name to “MyCredentialProvider” and press Enter to lock in.

4. In the Solution Explorer, right-click the MyCredentialProvider project node and select Properties. This will launch the MyCredentialProvider Property Pages dialog.

5. In the left tree view, select th= e Configuration Properties | C/C++ = node.

6. Make sure the path to your Vista= SDK include directory is included in A= dditional Include Directories. On a default install it ends up at “C:\Progr= am Files\Microsoft SDKs\Windows\v1.0\Include”.

7. In the left tree view, select th= e Configuration Properties | Linker= node to display the general properties of the linker configuration.

8. Make sure the path to your Vista= SDK library directory is included in A= dditional Library Directories. On a default install it ends up at “C:\Progr= am Files\Microsoft SDKs\Windows\v1.0\Lib".

9. Press OK to dismiss the dialog.

10. Open samplecredentialprovider.def. Change “SAMPLECREDENTIALPROVIDER.DLL” to “MYCREDENTIALPROVIDER.DLL”. Save samplecredentialprovider.def.

11. Open guid.h. Replace the GUID in DEFINE_GUID with a unique one. You = can generate a unique GUID from Tools | Create GUID. Be sure to remember it for later. Save guid.h.

12. Open Register.reg in notepad or Visual Studio (do not execute it in Explorer). Replace the GUIDs in each registry key with the one created in t= he last step. Also change “sampleprovider” to “MyCredentialP= rovider” as well as "SampleCredentialProvider.dll" to "MyCredentialProvider.dll". Save Register.reg.

13. Open Unregister.reg in notepad or Visual Studio (do not execute it in Explorer). Replace the GUID in the registry key with the one used in the Register.reg. Save Unregister.reg.

14. Select Build | Build Solution. If there are any build errors, review t= he steps above.

15. Copy the freshly built MyCredentialProvider.dll to the System32 directory of the test machine.

16. Copy Register.reg to the test machine and run it from Explorer to register the credential provider.

17. From the Start Menu, select the option to switch users.

18. The login screen should now have= an extra Administrator and Guest account. If all you see is one large tile, = click Switch User to see the list of tiles.

3Ddoc

19. You should be able to log in usi= ng the newly created Administrator account tile. The Guest account may or may not = be enabled due to the security settings of your system.

20. If you want to remove the sample= , copy Unregister.reg to the test mac= hine and run it to unregister the credential provider.

Tips & Tricks

The f= ollowing are some tips & tricks that can help you during the development cycle. These are useful to keep in mind when reviewing the other samples covered l= ater in this document.

Au= tomating The Deployment Process

If yo= u are developing on a test machine to begin with, you can automate the DLL deploy= ment process of by adding a Post-Build Event that automatically copies the output DLL to the System32 directory. For example, you can go to the Configuration Properties | Build Even= ts | Post-Build Event tab of the project’s Property Pages dialog and set the following for Command Line:

copy "$(OutDir)\$(ProjectName).dll" %systemroot%\system32 /Y

Howev= er, be careful when performing a second build since the Post-Build Event only occu= rs after a successful build, and Visual C++ will skip the build process if the binaries are already up-to-date.

De= veloping With CredUI

Altho= ugh you may not want to support the CredUI scenario in your final credential provid= er, you may wish to use it during development and debugging if you are developi= ng on the test machine. Since the CredUI scenario runs from a normal desktop session, you’ll be able to attach the Visual Studio debugger to it at runtime, drastically simplifying the process of development and testing.

To do= this:

1. Create a new Win32 console proje= ct in Visual Studio.

2. Update the main function of your= new project to make a call to CredUIPromptForWindowsCredentials, such as:

#include "stdafx.h"

#include <windows.h>

#include <WinCred.h>

int _tma= in(int argc, _TCHAR* argv[])

{

BOOL save =3D false;

DWORD authPackage =3D 0;

LPVOID authBuffer;

ULONG authBufferSize =3D 0;

CREDUI_INFO credUiInfo;=

credUiInfo.pszCaptionText =3D TEXT= ("My caption");

credUiInfo.pszMessageText =3D TEXT= ("My message");

credUiInfo.cbSize =3D sizeof(credUiInfo);

credUiInfo.hbmBanner =3D NULL;

credUiInfo.hwndParent =3D NULL;

CredUIPromptForWindowsCredentials(= &(credUiInfo), 0, &(authPackage),

NULL, 0, &authBuff= er, &authBufferSize, &(save), 0);

}

3. Update the project to link again= st CredUI.lib. You may need to update your “Additional Include Directories” and “Additional Library Directories” to poin= t to the Windows Vista SDK from the project’s property pages dialog.<= /o:p>

4. Add your credential provider pro= ject to the solution.

5. Build the credential provider an= d make sure the latest version is deployed to the System32 directory and is regist= ered as a credential provider.

6. Set breakpoints, etc, and then r= un the console app in debug mode. Your breakpoints should get hit as appropriate a= fter CredUIPromptForWindowsCredentials is called from the console app.

De= bugging LogonUI

In sh= ort: hook up kd between your test machine and your debugging machine and then pi= pe ntsd over kd for logonUI. There’s a fair amount of info on how to do this on the web (although not specifically for logonUI).&n= bsp; But here’s some basic pointers.

Install the debugger package (http://www.microsoft.com/whdc/devtools/debugging/default.mspx)
Get kd set= up between the two computers (for more info look on the web or MSDN)

Hook up y= our debug cable
On the de= bugee machine, run something like the following (change command line argume= nts as necessary)

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";mso-fareast-font= -family: Arial'> = &nb= sp; = i. Bcdedit –= debug on

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";mso-fareast-font= -family: Arial'> = &nb= sp; = ii. <= /span>Bcdedit –dbgsettings serial debugport:1 baudrate:115200

Reboot de= buggee
On debugg= er machine, run something like

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";mso-fareast-font= -family: Arial'> = &nb= sp; = i. Kd.exe –r –k com:port=3Dcom1,baud=3D115200

Copy symbo= ls that you will need locally to the box since NTSD won’t have acce= ss to the network
Create a key named logonui.exe under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
In the logonui.exe key, create a str= ing value named Debugger

Populate = that value with the path to ntsd.exe on your machine, for example C:\debuggers\ntsd.exe -d -gG -y <path to local symbols> = (space between –y and path required)
–d = pipes the NTSD output to KD
–g ignores the initial startup breakpoint in the process (if you want the process to break instan= tly when first executed to set BPs, do not set the small g)
–G ignores the termination breakpoint, so the process will exit quietly<= o:p>
–y = sets the local symbol path on the debugee for NTSD

Breaking i= n when a .DLL loads (not required, but good to know if needed)

Follow al= l of the steps above for the executable that loads the .dll, but do = not set the small g flag, then when the process starts, NTSD will bre= ak in
Type s= xeld <dll name>
Then g the debugger and NTSD will break in on load of that dll and you can set breakpoints, etc.

If= Your System Becomes Unstable

Durin= g the process of credential provider development, there is a good possibility that you might mess up the credential providers, possibly even crashing LogonUI.=

Don&#= 8217;t Panic.

Typic= ally, you can reboot Windows in safe mode (repeatedly tap F8 during early boot for the menu to do this). From safe mode you should be able to log in using the normal password provider, at which point you can unregister the offending credential provider.

The o= ther thing you might do is to accidentally unregister one or more of the built-in credential providers by deleting its key from the registry. For reference, = here are the keys from HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers:

Provider=	Key
Gen= ericProvider	{25CBB996-92ED-457e-B28C-4774084BD562}
PasswordProvider	{6f= 45dc1e-5384-457a-bc13-2cd81b0d28ed}
Sma= rtcard Credential Provider	{8b= f9a910-a8ff-457f-999f-a5ca10b4a885}

You s= hould be able to reenter them after rebooting in safe mode.

Sa= mpleAllControlsCredentialProvider

The SampleAllControlsCredentialProvider project illustrates the usage of each of the nine UI controls available to credential providers. Here’s an exa= mple of what you’ll see when you run this sample from LogonUI:<= /span>

Note = that the Cancel button is automatically inserted by LogonUI.

One o= f the nice things about this sample is that it differs only slightly from the base sample credential provider discussed earlier. Specifically, the key areas changed are in Common.h and CSampleCredential.h.

In Common.h, we’ve added more controls to the SAMPLE_FIELD_ID enumeratio= n, as well as respective entries for s_rgFieldStatePairs and s_rgCredProvFieldDescriptors. As you’ll see from the screenshots abov= e, only the “tile image” and “large text” are configur= ed to display in both selected and deselected mode, whereas the “small text” is configured to only appear when the tile is deselected. All o= ther controls appear only in the selected tile. To change this behavior, modify = the second member of the s_rgFieldStatePairs (it’s a CREDENTIAL_PROVIDER_FIELD_INTERACTIVE_STATE).

In ad= dition to the new fields in Common.h, it’s necessary to add in support for e= ach type of control to the CSampleCredential.cpp implementation. By default, the base sample only implements support for the String and Bitmap methods, such= as GetStringValue, etc. Since those are the only types of controls used in the sample, it was fine to return E_NOTIMPL from the unused control methods, su= ch as GetCheckboxValue. However, since we’re using these controls now, we’ve implemented support for getting and setting their respective values.

Control<= /p>	Required Methods
SFI= _TILEIMAGE	Get= BitmapValue
SFI= _LARGE_TEXT, SFI_SMALL_TEXT	Get= StringValue
SFI= _EDIT_TEXT, SFI= _PASSWORD	Get= StringValue, Set= StringValue
SFI= _SUBMIT_BUTTON	Get= SubmitButtonValue
SFI= _CHECKBOX	Get= CheckboxValue, Set= CheckboxValue
SFI= _COMBOBOX	Get= ComboBoxValueCount, Get= ComboBoxValueAt, Set= ComboBoxSelectedValue
SFI= _COMMAND_LINK	Get= StringValue, Com= mandLinkClicked

SampleCredent= ialFilter

The I= CredentialProviderFilter interface is used to disable one or more credential providers from enumerating. The Filter metho= d of the interface is called by LogonUI or CredUI with two parallel arrays of credential provider CLSIDs and BOOL variables; the filter’s implementation should set the BOOL corresponding to a credential provider to FALSE if that credential provider should be prevented from enumerating.

The s= ample credential provider implementation compares each credential provider CLSID against a hard-coded CLSID and, if it matches, disables that credential pro= vider. The hard-coded CLSID is GUID_NULL,= which is not a valid CLSID. The use= r of the samples should replace GUID_NULL with the CLSID credential provider they would like to disable. For ex= ample, one could replace GUID_NULL with the CLSID of one of the sample credential providers described in this document.

Care = should be used when replacing GUID_NULL with the CLSID of a credential provider th= at is needed to log on to the test system.&nb= sp; If the filter mistakenly prevents a necessary credential provider fr= om enumerating, see the discussion of Safe Mode in the FAQ section at the end = of this document.

Sa= mpleCredUICredentialProvider

Windows Vista introduced, and Windows 7 continues to support, CredUIPromptForWindow= sCredentials, which can be thought of as the next generation of CredUIPromptForCredentials (although CredUIPromptForCredentials is still maintained for backwards compatibility). Unlike CredUIPromptForCredentials, CredUIPromptForWindowsCr= edentials relies on the same credential providers used by the login screen. While implementing these credential providers are fundamentally the same, there is one place you’ll need to make a decision regarding how your credential provider works.

The implementation of CSampleProvider::SetUsageScenario contains everything we = need to add support for CredUI. This method is called with a specific usage scen= ario (a CREDENTIAL_PROVIDER_USAGE_SCENARIO), which asks the credential provider = if it supports it. By default, SampleCredentialProvider does not support the CPUS_CREDUI usage scenario, which means that an application using CredUIPromptForWindowsCredentials will not be able to access credentials provided through it. However, we have changed this for the SampleCredUICred= entialProvider by having requests for the CPUS_CREDUI scenario treated in the same way as CPUS_LOGON – so it will enumerate the same two tiles in the Credui scenario.

SampleHardwareEventCred= entialProvider

A com= mon scenario for custom credentials involves external events, such as the arriv= al of a message generated by a fingerprint scanner. The SampleHardwareEventCreden= tial sample illustrates processing asynchronous events such as these.=

When = run, this sample displays a window with a single button. This window is designed= to emulate an external element that has two states: connected and disconnected. When disconnected, the credential merely displays a large text asking the u= ser to connect:

By pr= essing the “Press to connect” button, you simulate a hardware event su= ch as swiping a fingerprint and the credential provides different controls, allowing the user to log in:

Since= you cannot change the controls used by a particular credential while handling a hardware event (because you haven’t been Advised on ICredentialProviderCredentialEvents), this sample actually implements two credentials: a “please connect” message credential and an actual “log in” credential, which is effectively the same as the CSampleCredential from the SampleCredentialProvider project. Depending on t= he state of the connection emulator window, the provider displays the proper o= ne.

The w= indow is created on a separate thread, which provides it with a way to pump messages while the provider thread is managed by an external authority. When the but= ton is pressed, the window thread calls in to the provider, asking it to re-enumerate its credentials by calling the CredentialsChanged method on the ICredentialProviderEvents pointer it received in an earlier Advise call:

When = the credentials are enumerated, methods like GetCredentialCount and GetFieldDescriptorCount are called again. In turn, the provider checks the state of the connection emulator and provides data for the appropriate credential. In either case, exactly one credential is always displayed. Note that we’re calling CredentialsChanged from a separate thread, which is okay to do. However, be extra careful when trying to call other methods from the separate thread.

While= this sample illustrates using a button on a window as an event, you could custom= ize CCommandWindow::ThreadProc to look for any event you need, provided it̵= 7;s supported on the secure desktop.

Sa= mpleWrapExistingCredentialProvider

In so= me scenarios, you may find that an existing credential provider fits almost al= l of your needs, with the exception of an additional field or two you need to retrieve from the user. It would be a shame to have to re-implement the functionality of the existing credential provider, so this sample illustrat= es the process of wrapping an existing credential provider and extending it wi= th two additional fields.

In our scenario, we simply attached an extra small text and combobox to the existi= ng password provider’s credentials. We’ll let the existing credent= ial provider decide how many credentials to enumerate, how to enumerate them, a= nd how to authenticate. We’ll also let it deal with the behavior for the controls it defines.

Crede= ntial providers are COM objects, so they can be created and managed just like any other COM object. In our scenario, we use the CLSID_PasswordCredentialProvi= der found in CredentialProvider.h to instantiate the provider, and then we proxy most of the calls through to it, returning the results as though they were = our own. However, if we receive calls related to our specific extensions, we ha= ndle those ourselves.

Since= we don’t want to limit the functionality of the wrapped credential, it’s important to avoid assumptions where possible. For example, we don’t use a checkbox in our extension, but it is possible that the un= derlying credential may (if not now, then possibly sometime in the future). As a res= ult, calls to methods we don’t do anything for should still be passed alon= g to the wrapped credential.

In so= me cases, we do handle calls that our wrapped credential needs as well. Fortunately, we can use the dwFieldID parameter to determine whether the referenced fields are ours or theirs. Since our sample appends controls to = the wrapped credential, we can perform a simple check to see if the field is ou= rs or theirs

Howev= er, if you decide to insert controls between controls in the wrapped credential, you’ll need to be extra careful to track which field IDs are yours and which are theirs.

For s= ome well-known credential fields, such as the password provider’s password field, you can determine their location by checking the guidFieldType prope= rty of their CREDENTIAL_PROVIDER_FIELD_DESCRIPTOR. For example, password field’s CLSID is CPFG_LOGON_PASSWORD. More well-known CLSIDs are available in shlguid.h.

Default Tiles

A Credential Provider may specify a default tile when queried regarding the number of tiles it intends to return. Although this is straightforward from= the perspective of each individual Credential Provider, developers should keep = in mind that LogonUI will not necessarily treat their tile as the default in a= ll cases. The Credential Provider most recently used for interactive logon will receive preference when multiple providers return a default tile. In other words, when two or more providers return a default tile, the tile specified= by the Credential Provider last used to log on will be displayed in zoomed vie= w. This behavior does not occur in a remote session because the most recently = used Credential Provider is not saved.

Credential Providers may also specify default tiles for the Cr= edUI usage scenario. The default tile in this scenario will receive focus when CredUI appears to the user. CredUI resolves multiple default tile conflicts using the same logic as LogonUI. There is no way for a Credential Provider = to determine if other providers specify a default tile.

The default tile provided by the Credential Provider last used= to successfully logon does not need to be the same tile used during the previo= us logon. The Credential Provider is free to specify any of its tiles when it enumerates the default.

Wrapping Existing Credential Providers

Although Microsoft provides a wrapped Credential Provider samp= le, it is very important that all third parties proceed with extreme caution wh= en implementing a wrapped provider. As long as instantiating multiple instance= s of the wrapped Credential Provider does not cause problems, wrapping is a safe technique and allows third party developers to avoid rewriting code. = For instance, if the wrapped Credential Provider stores anything globally there= may be issues creating two instances. The Microsoft in-box providers shou= ld be safe to wrap by third parties.

Developers need to be aware that wrapping can be very dangerou= s if a Credential Provider filters out the original instance of the wrapped provider. In certain situations this is acceptable, but the consequences of unanticipated filtering should be considered to avoid unexpected (and undesirable) consequences.

IT Professionals writing Credential Providers which filter out= providers on every box in a domain are most likely safe to filter at their discretion. These administrators own the experience on the desktops in their domain. Du= e to the nature of the controlled environment, they most likely do not need to w= orry about conflicting filters unexpectedly breaking their machines. Best practi= ces should be followed when installing new Credential Providers. Deploy in a st= aged environment prior to rolling your changes out to the entire domain.

If you are an ISV or an OEM designing a Credential Provider intended for deployment to desktops you do not control then you will want to proceed with much greater caution. For instance, consider a case where two separate credential providers each wrap and filter the in-box password prov= ider. Imagine at least one of them performs an operation effecting the entire mac= hine before logon. Consider what happens when a user installs both these hypothetical credential providers on the same machine. During logon only on= e of them will be used. In this scenario the user can reach the desktop without performing an important operation specified by one of the credential providers. =

In general, you should

= -      = Only filter out other Credential Providers if you explicitly ask and obtain permission from the a= dministrator in charge of setup

= -      = Not filter out any o= f the built-in providers (for instance, the password provider) unless one of the following is true

o   Not filtering an in-box provider will cause user confusion.&nb= sp; Consider the consequences of not filtering the in-box provider – if it does not severely impact user experience (and wouldn’t cause bad prob= lems if a user logged on using this in-box provider), you probably do not need to filter it out.

o   If you are an OEM or ISV and you are guaranteed to be the only= 3^rd Party Credential Provider on the box, then you are essentially in ITPro category above and you should have no problem.

If you are not guaranteed to be the only Credential Provider on the box then you may introduce possible instabilities if you filter any built-in providers. Some Credential Provider authors might be tempted to do this in order to force users to use the installed 3^rd party Credential Provider for all logons (for instance, to run a script). I= t is bad practice to depend on users logging on using a specific Credential Provider. Third Party Credential Provider authors generally should not assu= me there will not be other Credential Provider installed on the user’s system.

Credential Provider Architecture

Unlike a GINA, Credential Provider authors cannot and should n= ot write their code provider to enforce running certain code at every logon.&n= bsp; Unless it is absolutely guaranteed that another Credential Provider will ne= ver be installed on a the user’s machine, developers should design Creden= tial Providers to provide a way for the user to log on without guarantees that t= heir Credential Provider will be used for log on in all circumstances.

Credential Providers are intended to run in parallel. Using wrapping and filtering to attempt to force behavior similar to the GINA model of chaining should not = be used unless you are guaranteed no other 3^rd party Credential Provider will be installed on the box

Appendix A – Frequently Asked Questions

General Questions. 18<= /o:p>

Serialization. 21

Secure Attention Sequence (CTRL+ALT+DEL) 22

Sessions, the Desktops, and the Credential Provider Life-Cycle. 22

GINA Migration. <= /span>23

X86 and X64. <= /span>23

Filters and Uninstalling Credential Providers. <= /span>24

Single Sign On Scenarios. 24

Logon UI 25

CredUI = 26

COM.. 26

General Questions

Q= : I'm having a pr= oblem with my Credential Provider. Can I send my source code to someone at Micros= oft for review?

A= : No. Please do n= ot send any source code to the Shell Credential Provider alias. We are happy to provide to answer your questions and provide assistance as you develop your credential provider but will delete any source code you send without review= ing it. It is ok to send pseudo-code (non code that will provide an idea of what you’re trying to do), but please do not send complete function definitions or class implementations. This is important - since it protects= our partners, our customers (like you!) and Microsoft.

Q= : Help! my Creden= tial Provider is busted and I can't uninstall it! What should I do?

A= : Don't panic. Re= start the machine and logon in SAFE mode (hold F8 down during boot to bring up a = menu where you may choose SAFE mode). Once in safe mode, launch regedit and un-register your Credential Provider from HKCR and HKLM. You should now be = able to re-boot your computer and logon in normal mode.

Q= : I= want to map third-party unique identities (such as private certified names) into unique Windows credentials. Is this possible?

A= : Y= es, your Credential Provider needs to collect the third-par= ty unique identity, retrieve the Windows principal name from the third-party account directory, and serialize credentials for the local account. This co= de should be placed in ICredentialProviderCredential::GetSerialization().<= o:p>

Q: Is= it possible for my Credential Provider to make changes to other Credential Provider Tiles?

A: Cr= edential Providers should limit themselves to handling their own tiles.

Q= : How can I displ= ay more than 10 Credential Provider fields?

A= : This is not supported.

Q= : Where can I find credentialprovider.h ?

A= : By default, credentialprovider.h is installed at "%systemdrive%\Program Files\Microsoft SDKs\Windows\v6.0\Include".

Q= : I want to write= a Credential Provider. Where should I start? Is there an overview document explaining ho= w to write a Credential Provider?

A= : Download the our published samples and technical reference. The technical reference contains= an overview of the framework (as well as specific details explaining the interfaces). The zip contains an overview document explaining how to build = the samples. It also includes pointers for registering and debugging your code.=

Q= : Is it possible to develop a Credential Provider for Windows Vista using Visual Studio .NET 2003?

A: No= . Credential Provider development requires the Windows Vista SDK = or the Windows 7 SDK. The Windows Vista SDK requires Visual Studio 8 or higher. The Windows 7 SDK requires Visual S= tudio 9. Developing Credential Prov= iders in Visual Studio .NET 2003 is not supported.

Q= : The technical r= eference refers to "tiles". What exactly these? Is there an underlyi= ng object I may access/customize?

A= : Tiles correspon= d to instances of ICredentialProviderCredential. You will need to implement this interface (or IConnectableCredentialProviderCredential in order to control = the behavior and fields of your Credential Provider's tiles. =

Q= : Where can I fin= d the latest technical reference for Credential Providers?

A= : The latest docu= ment we published for download is the Credential Provider Technical Reference.

Q= : I want to retur= n the image associated with a local user account for CPFT_TILE_IMAGE. Where is this image located?

A= : This is not supported.

Q= : I noticed the P= assword Provider lives in AuthUI.dll. If I de-register the in-box Password Provider= , is it safe to delete AuthUI.dll?

A= : No. Windows Vis= ta requires AuthUI.dll for other functionality.

Q= : What is the pur= pose of the Generic Provider?

A= : The Generic Pro= vider serializes a CPCSS with containing two strings. These strings are not encrypted. The Generic Provider Filter is used to ensure only the Generic Provider is instantiated within CPUS_CREDUI when the CREDUIWIN_GENERIC flag= is passed to CredUIPromptForWindowsCredentials.

Q= : I want to devel= op my own Smartcard Credential Provider. Where should I start? How can I detect S= mart Card removal/insertion?

A= : You will want to begin with the Hardware Event Credential Provider sample (see the question above). Your provider will be responsible for detecting smartcard insertion/removal, using SCardGetStatusChange. The other SCardXXX APIs will also be of interest as you develop.

Q= : Why aren’t Credential Providers instantiated with CPUS_CHANGE_PASSWORD when users navi= gate to 'Control Panel' -> 'Classic View' -> 'User Account Control Panel' -> 'Change your Password'?

A= : We wanted to pr= ovide novice users in the home environment a simple and easily discoverable metho= d to change their password. Many users are accustomed to changing their password through this path. Since the control panel, by design, runs in the standard user's security context, we do not load Credential Providers on this control panel.

Q= : I want to imple= ment a Credential Provider which responds to a hardware event (such as smart card insertion). Is there sample code available?

A= : Yes, one of our published samples demonstrates a Credential Provider reacting to a (simulat= ed) hardware event. It provides a good place to start developing a hardware eve= nt driven Credential Provider.

Q= : Have there been= any updates to the Windows Vista Credential Provider architecture, API, error codes, or UI in the Vista RC2 release comparing to the RC1? Will it change in the upcoming RTM release?

A= : The Credential = Provider interfaces have not changed since RC1. In order to help provide our partners and customers ample time to prepare for Windows Vista, our team has worked = very hard to freeze all interfaces since April, 2006.

Q= : I want to displ= ay a dialog box to collect/display information for my Credential Provider. How c= an I do this?

A= : In order to dis= play a MessageBox or dialog, you will need retrieve the Logon UI’s hwnd. To = do this, you must call ICredentialProviderCredentialEvent::OnCreatingWindow(). Parent your dialog to this hwnd. Trying to display a dialog using any other parent hwnd is not supported. Credential Providers using any other method to show dialogs during a CPUS can hang the system under anticipated circumstan= ces.

Q= : Why doesn't the in-box Password Provider include a domain drop-down, like the one that came= by default in Windows XP?

A= : We eliminated t= he domain drop down in Windows Vista for the following reasons:

-       DsEnumerateDomainTrusts(), the function we called previously to enumerate domains in the drop down, was not guaranteed to return a complete list. It is designed to make a best eff= ort, but in some cases would return only a partial list

-       Any third parties calling DsEnumerateDomainTrusts() will want to store a cached list of domain names in order to prevent users from becoming confused in the event their domain is not returned

-       By design, this API will try to retrieve the list of domains by checking resou= rces over the network. This caused performance issues.

-       Third parties authoring a custom Credential Provider calling this function should= be aware they can hang LogonUI if the call takes a long time to return. To pre= vent this, their solution should be architected so that the call occurs asynchronously.

Customers who require the drop down list available in XP may create a Credential Prov= ider that includes this list in its fields. In most organizations, the logic to populate this list will not need to leverage DsEnumerateDomainTrusts. Inste= ad, call a remote service or check a cached list on the machine which is updated via script that runs after logon.

Q= : Which Microsoft Credential Providers ship in-box on Windows Vista?

A= : The GenericProv= ider, NPProvider, PasswordProvider, RasProvider, and Smartcard Credential Provider ship in-box. These providers (as well as any third party providers installe= d on the machine) are listed under "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credent= ial Providers" and "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\PLAP Providers".

Q= : My implementati= on of ICredentialProviderCredential::ReportResult is not called if an error is encountered after serialization in CPUS_CREDUI. Is this a bug?

A= : No, this is not= a bug. ReportResult is not called in CPUS_CREDUI.

Q= : My Credential Provider attempts to autosubmit by returning a default credential and setti= ng pbAutoLogonWithDefault to true. When incorrect credentials are serialized, = my tile continually attempts to auto-submit and enters an endless loop. What's wrong?

A= : There are two different approaches to solving this problem.

-       You may create an internal structure to track your attempt to autosubmit credentials and, in the failure case, check it within ICredentialProviderCredential::ReportResult. From there you may change your structure to indicate you do not want to autosubmit, or take some other act= ion.

-       Another approach to the problem is to have your Credential Provider enumerate more = than one tile. When GetCredentialCount is called, designate a default tile and attempt to autologon using it. In the event of failure, the user will see t= he second (and likely empty) credential tile. This seems less intuitive than t= he alternative (re-enumerating on autologon failure), however you will find it= is simpler to code.

Q= : I can't seem to= set the interactive states of my Credential Provider fields to read-only or disable= d. I attempt to specify CPFIS_READONLY and CPIFS_DISABLED but this doesn't seem = to work. What's wrong?

A= : Nothing is wron= g with your code. CPFIS_READONLY and CPFIS_DISABLED are not implemented for Windows Vista. We plan to add support for these interactive states in a future rele= ase.

Q= : How can I get my Credential Provider to respond to AutoAdminLogon?

A= : Set HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon “AutoAdmin= Logon” to 1, filter the Password Provider, and submit a credential to autologon wi= th.

Q= : I want to confi= gure my Credential Provider to perform autologon. How may I accomplish this?

A= : In order to do = this, you must set configure the machine for auto logon, configure your Credential Provider to specify a default credential, and set pbAut= oLogonWithDefault to true. To set configure your machine for autologon, you must set the following registry k= ey

[HKEY_LOCAL_M= ACHINE\SOFTWARE\Micro= soft\Windows NT\CurrentVersion\Winlogon]

“AutoLogonAdmin<= /span>”=3D= 221;1”



Q= : I would like to= hide and reveal one a field in my Credential Provider dynamically. How can I do this?

A= : When your tile = is advised, use methods exposed by ICPCE. When your tile is not advised, you m= ust perform a full re-enumeration in order to change a field’s state from hidden to unhidden.

Q= : I downloaded th= e Beta 2 samples and tried to compile them. I get an error trying to link to bufferoverflowu.lib. What should I do?

A= : Changes in the = build and SDK exposed this problem after we released the Beta 2 samples. We will release new versions of the samples at RTM. Check on msdn to see if the upd= ated versions are available. You may also correct the problem with the samples y= ou currently have by taken the following steps...

-       Comment out the line “#include <winres.h>” in resource.rc

-       In the solution explorer, right-click the node below the top-level solution and select Properties from the context menu

-       A dialog will open

-       In the left-hand tree control, navigate to Configuration Properties =3D> Li= nker =3D> Input

-       Remove bufferoverflowu.lib

-       Add gdi32.lib, ole32.lib, user32.lib

Serialization<= o:p>

Q= : My application respects the GP Setting indicating smartcard must be used for domain creden= tials. I don't want to uninstall or filter the Password Provider, but I don't want password providers to enumerate in CredUI. How can I prevent non-smartcard providers from enumerating?

A= : Simply stated, CredUIPromptForCredentials has no way to specify "smartcard only". Since both the Smart Card Provider and the Password Provider recognize the Kerberos authentication package, passing in Kerberos as the auth package wi= ll not prevent the Password Provider from enumerating credentials. To work aro= und this limitation, your application must pass a partially filled Smart Card credential blob as well as the flag CREDUIWIN_IN_CRED_ONLY when calling CredUIPromptForWindowsCredentials. Refer to the Credential Provider Samples= for additional information. Alternatively, if your credential provider is not capable of serializing Kerberos certificate credentials, it is good practic= e to register a filter and prevent your credential provider from enumerating til= es when this policy setting is enabled.

Secure Attention Sequence (CTRL+ALT+DEL)

Q= : How can I initi= ate Ctrl+Alt+Del from my Credential Provider?

A= : This is not supported. Requiring Ctrl+Alt+Del (CAD) for interactive logon is intended to defeat spoofing (for the purposes of credential harvesting). A Credential P= rovider generated substitute for this sequence does not provide protection against spoofing. Treating arbitrary hardware events (such as USB insertion, Smartc= ard insertion, etc) does not initiate a transition to the secure desktop in all scenarios. As a result, it's possible for an application running with stand= ard user privileges to spoof the logon screen and steal a users credentials. Organizations who consider CAD to be inconvenient are able to disable the G= roup Policy setting requiring CAD during interactive logon. We encourage organizations to carefully consider the security implications of disabling = this group policy setting before doing this.

Sessions, the Desktops, and the Credential Provider Life-Cycle

Q= : Is my Credential Provider loaded in Session 0?

A= : Your Credential Provider is instantiated in the same session as LogonUI. In Windows Vista, = Session 0 is reserved for services and is almost never visible. When it is visible, LogonUI is not. The particular TS session your Credential Provider is instantiated is generally not a useful piece of information.

Q: Which desktop does LogonUI instantiate my Credential Provider on?

A: TS Sessions contain a single Window Station. This Station has may contain mult= iple desktops. LogonUI loads your Credental Provider on the Winlogon desktop.

Q= : Is it permitted= to use my Credential Provider to run SYSTEM applications on the Winlogon Deskt= op?

A= : Although Windows Vista does not explicitly prevent SYSTEM applications from running on the Winlogon Desktop, this practice is not recommended and is strongly discoura= ged. SYSTEM privileges may be used to gain access to any resource on the compute= r. Running SYSTEM applications on the winlogon desktop exposes security vulnerabilities.

Q: Do= I need to worry about malware running on the user desktop trying to sniff key strokes entry on the Winlogon Desktop?

A: De= sktops are an isolation boundary for windows messages. Unless the TCB is compromis= ed, your Credential Provider should not need to worry about this problem. =

Q= : Is it permitted= to use my Credential Provider to run USER applications on the Winlogon Desktop= ?

A= : USER applicatio= ns may not run on the Winlogon Dekstop.

Q= : How long does my Credential Provider exist?

A= : In order to ens= ure forward compatibility with future versions of Windows, we recommend architecting your Credential Provider to collect and serialize credentials. Providers that depend on being created and destroyed at a specific time are= not guaranteed to be forwards compatible.

Q= : Does my Credent= ial Provider exist throughout an entire TS session?

A= : No. Credential Providers are created when necessary and then destroyed. LogonUI and CredUI both destroy Credential Provider objects before exiting. =

GINA Migration<= o:p>

Q= : My organization= used a custom GINA in a previous version of Windows. How do Credential Providers interact with GINA?

A= : They do not. Beginning with Windows Vista, Gina’s are no longer supported. Your solution will need to be re-factored in order to work properly on Windows V= ista.

Q= : I used biologon= .dll with my GINA in Windows XP. Will this work in Windows Vista?

A= : No. Biologon.dl= l does not work with Windows Vista.

Q= : Are notification packages supported in Windows Vista?

A= : Winlogon Notifi= cation Packages are no longer supported. Please refer to the published whitepaper = Winlogon Notification Packages Removed Impact on Windows Vista Planning and Deployme= nt.doc.

Q= : In previous ver= sions of Windows Vista, I wrote a custom GINA and registered a custom Winlogon Notification Package to detect events such as StartShell and StopScreenSave= r. How can I use this in Windows Vista?

A= : If you wish take action on a state transition in Windows Vista, you will need to use SENS or= SCM notifications. Both solutions can be used on Windows Vista and earlier versions.

Q= : My GINA used to= load an application after the user successfully logged on. How can I do this wit= h my Credential Provider?

A= : Credential Prov= iders are responsible for gathering information for the purposes of authentication and packaging that information as a credential blob. Credential Provider sh= ould not be designed to start applications to run on a user desktop on behalf of= a specific user. In a perfect world the Credential Provider will already have been destroyed by the time applications are allowed to start as the logged = on user. Technologies such as startup scripts are more appropriate for this pu= rpose.

X86 and X64<= o:p>

Q= : I downloaded the latest SDK, but I don't see the libraries I need to build 64-bit Credential Providers. Where can I find these libraries?

A= : On x86 machines, 64-bit libraries are not installed by default. You must specifically select= to install them during setup. Do this by drilling down through the nodes of the tree control the optional components.

Q= : In Windows Vist= a x64, is a 32-bit CSP required to support custom CAPI?

A= : When a 32-bit application, running on a 64-bit machine, calls CredUIPromptForWindowsCredentials, 32-bit versions of the Credential Provid= ers are needed in all scenarios where secure desktop prompting is not enabled. = Any 32-bit CAPI application will also use the 32-bit CSPs and card modules in t= his case. 64 bit versions of the Credential Providers, CSPs, and card modules a= re needed to support this scenario when secure prompting is enabled.

Q= : Does the windows logon process use the 32 or 64 bit version of the CSP for smart card logon?=

A= : LogonUI is alwa= ys native.

You will need to compile a 64 bit version of your Credential Provider in order = to support CPUS_LOGON on machines running a 64-bit version of Windows Vista.

Q= : On Windows x64 = bit platform, if an application using CAPI (for smart card logon for example) is running in 32 bit, will the WOW64 transparently redirect the CSP calls to 64 bit version of registered CSP or should two versions of the CSP be register= ed in the system, one for 32 and one for 64 bit applications?

A= : Dlls like crede= ntial providers (CPs) and CSPs (and card modules) need to match the version of th= eir host (the exe). 64-bit exes load only 64-bit dlls. 32-bit exes load only 32= -bit dlls. You may need 32-bit versions of the each component on 64-bit platform= s in order to support WOW64.

Filters and Uninstalling Credential Providers<= /b>

Q= : Does the Shell Credential Provider team publish sample code illustrating how to implement ICredentialProviderFilter?

A= : No. Please refe= r to the Credential Provider Technical reference for details regarding authoring= a Credential Provider Filter.

Q: My implementation = of ICredentialProviderFilter is not loaded in SAFE mode. Is this a bug? Is the= re a way to run my Filter in SAFE mode?

A= : This is not a b= ug. SAFE mode is intended to serve as a workaround in order to correct repair Operating Systems malfunctioning due to incorrectly configured components s= uch as device drivers. By default, only the in-box Password Provider is loaded = in SAFE mode. The in-box Smart Card Provider is also available if the machine = is booted into SAFE mode with networking. This provides a fallback in case of a bad error. To over-ride the fallback logic and force logonUI to load Credential Provider filters in SAFE Mode, create and set the following registry key:

[HKEY_LOCAL_M= ACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers]

“Prohib= itFallbacks”=3Ddword:1

Important Note<= /span>: By setting this registry key, you w= ill explicitly override the fallback safety mechanism Windows Vista supplies to= troubleshoot configuration errors and malfunctioning Credential Providers. Users may be blocked from logon in the event of Credential Provider failure.<= /span>

Q= : Is it possible = to de-register the in-box Credential Providers?

A= : Yes, these may = be de-registered just like any other COM object. They are registered under HKEY_CLASSES_ROOT\CLSID. Please refer to CredentialProvider.idl for a compl= ete list of Credential Providers which ship in-box and corresponding CLSIDs.

Important note: By default, Windows Vista requires the Password Provider and Smart Ca= rd Provider to boot into SAFE mode. After de-registering Credential Providers = on a machine, you will need to prohibit fallbacks (see question above) in order = to load new Credential Providers in SAFE mode.

Single Sign On Scenarios

Q= : I want to creat= e a VPN connection after authentication. How can I do this with a Credential Provider?

A= : Credential Prov= iders are destroyed after logon. Connecting to a VPN after logon requires a netwo= rk provider.

Q: Is it poss= ible to write a single sign on Credential Provider supporting 802.1x Authentication= + Windows logon?
A: <= /span>Yes. IC= onnectableCredentialProviderCredential, which inherits all methods from ICredentialProviderCredential, is suitable = for this scenario. Your Credential Provider should collect credentials from the user and use them to connect to the a WAP through IConnectableCredentialProviderCredential::Connect().If the connection is successful, attempt to Serialize credentials for local machine logon using GetSerialization().

Note: Connect() will = always be called before GetSerialization().

Q= : Do you offer a = sample Credential Provider illustrating this?

A= : No.<= /span>

Logon UI<= o:p>

Q= : May I add items= to the security options screen?

A= : This is not supported.

Q: Will a CP implementing CPUS_LOGON work in TS?

A= : Yes it will, si= nce LogonUI in remote sessions loads CPs normally.

Q: I’d like to display a common contro= l on Logon UI that doesn’t exist in the control set defined by the Credent= ial Provider. Is this possible?

A= : This is not recommended or supported.

Q: I&= #8217;ve used ICredentialProviderCredentialEvents::OnCreatingWindows() to retrieve LogonUI’s HWND, and display a dialog parented to LogonUI. My dialog doesn’t appear with Glass and aero-themed menus. Why not? =

A: The theme service is not enabled on the Winlogon Desktop. The theme serv= ice provides visual styles for Windows and applications. It is not possible to = use glass, specify fonts, or specify colors for your dialog without the theme s= ervice.

Q= : How can I chang= e the background of LogonUI?

A= : This is not sup= ported in Windows Vista.

Q= : How do I write = my Credential Provider to autosubmit credentials when it has all the required information?

A= : Your Credential Provider may autosubmit Credentials in two ways.

-&nb= sp;      Specify a default Credential and set pbAutoLogonWithDefault to true in response to GetCredentialCount()

-&nb= sp;      Set pbAutoLogon to true in response to SetSelected()

Both of these methods will cause a call to GetSerialization (and Connect() if the credential is an instance of IConnectableCredentialProviderCredential). To initiate auto-submission of credentials at a an arbitrary point in time, yo= ur provider may call ICredentialProvider::CredentialsChanged. This call will f= orce a full re-enumeration of credential tiles. When LogonUI calls ICredentialProvider::GetCredentialCount, specify a default tile and set the value of pbAutoLogonWithDefault to true (as mentioned above).

Note: Developers should be aware that race conditions may exist if another provider installed on the machine also requ= ests to autologon with the default during this call. Please refer to the technic= al reference for a detailed explanation of the logic LogonUI uses to decide wh= ich credential to submit to Winlogon in this case.

CredUI

Q= : What is CPUS_CR= EDUI?

A= : Windows Vista introduces a new public API for credential collection, CredUIPromptForWindowsCredentials. To see an instance of this A= PI being used to collect credentials, open the remote desktop client (mstsc.ex= e), specify a target machine, and click 'connect'. The Windows Security dialog that app= ears loads Credential Providers in the CPUS_CREDUI scenario. <= /p>

Q= : My application = calls CredUIPromptForCredentials. How can I leverage Credential Providers using t= his API?

A= : CredUIPromptFor= Credentials is very different than CredUIPromptForWindowsCredentials. The legacy API (CredUIPromptForCredentials) is not aware of Credential Providers. In order= to collect credentials within your application using Credential Providers, you= must revise your application's code to call CredUIPromptForWindowsCredentials. <= o:p>

Q= : How can I call = CredUI and specify it only load a specific Credential Provider?<= /p>
A= : In general, thi= s is not supported. Credential Providers aim to support credential agility. This means that if

an application accepts Kerberos credentials, any credential provider that knows how to serialize Kerberos credentials will be able to be used. <= /span>

Q= : How can I speci= fy my Credential Provider to load in the User Account Control Prompt? =

A= : If your credent= ial provider supports CPUS_CREDUI, it will be available in the UAC prompt. To support the CredUI usage scenario, your provider must return S_OK when CPUS_CREDUI is passed in thro= ugh SetUsageScenario(). Your provider must indicate it will enumerate at least = one tile in in response to GetCredenitalCount() and then supply the credential = in GetCredenialsAt(). Under normal circumstances, if your provider behaves in = this way, your tile will appear in the UAC prompt.

Note= : Please refer = to Group Policies related to the UAC prompt. Specifically, if you intend for y= our credential provider to appear in the UAC prompt, it should respect the Group Policy setting “Enumerate administrator accounts on elevation”. Please refer to this GP for more information.

Q= : How can I differentiate between CPUS_CREDUI for credential collection in TS and credential collection in the UAC prompt?

A= : In general, we encourage Credential Provider authors to write their CP such that no differentiation in these two states is necessary. Enumerating a default (or 'empty') tile in CREDUI_CPUS is a good practice. Developers may examine the flags passed in ICredentialProvider::SetUsageScenario to gather more context regarding the scenario at run time. Specifically, CREDUIWIN_ENUMERATE_ADMINS will always be passed in CPUS_CREDUI when tiles are requested for the UAC dialog. Note: Referring to UAC specifically in your credential provider when you see CREDUIWIN_ENUMERATE_ADMINS is bad form since this flag may be passed during credential collection with CredUI in scenarios other than the UAC dialog.

COM

Q= : How may I call methods exposed by ICPCE?

A= : Methods exposed= by ICPCE may only be called when your provider is advised. Your provider is advised around ICPC calls. Your provider is responsible for storing the ICP= CE pointer while advised, and should null this pointer when unadvised. Do not = pass the ICPCE pointer to other threads and attempt to call these methods. The I= CPCE interface must be called from the credential provider’s thread. =

Q= : What apartment threading model should I write my CP to run in?

A= : CPs must be wri= tten to run STA.

Q= : May I call the methods on the ICPE interface asynchronously?

A= : Yes, the method= s on the ICPE interface can be called asynchronously.

Q= : Do credential providers ever have to worry about reentrancy?

A= : No. There are no supported scenarios in which Credential Providers need to worry about reentrancy.

-&nb= sp;      A separate TS session (with individual instances of Winlogon and LogonUI) is = used each time a user is prompted for logon credentials.

-&nb= sp;      Calls to CredUIPromptForWindowsCredentials return after a credential provider successfully serializes credentials. <= o:p>

Q= : Can CPs be implemented in managed code through COM interop? Or must they be nati= ve code?

A= : Microsoft recom= mends all code running in system context be implemented in native code. We do not support Credential Providers written in managed code.

= Terms of Use

The SampleCredentialProvider Codebase=

SampleCredent= ialFilter

SampleHardwareEventCred= entialProvider

Appendix A – Frequently Asked Questions

=
Terms of Use