Credential Providers in Windows 10

Credential providers are the primary mechanism for user authentication—they currently are the only method for users to prove their identity which is required for logon and other system authentication scenarios. With Windows 10 and the introduction of Microsoft Passport, credential providers are more important than ever; they will be used for authentication into apps, websites, and more.

Microsoft provides a variety of credential providers as part of Windows, such as password, PIN, smartcard, and Windows Hello (Fingerprint, Face, and Iris recognition). These are referred to as «system credential providers» in this article. OEMs, Enterprises, and other entities can write their own credential providers and integrate them easily into Windows. These are referred to as «third-party credential providers» in this article. Note that both V1 and V2 credential providers are supported in WindowsВ 10. It is important for creators and managers of third-party credential providers to understand these recommendations.

System credential providers

We strongly recommend that there always be at least one system credential provider available for every user on the device in addition to any third-party credential providers. Additionally, during the set-up of the third-party credential provider, each user on the device should be prompted to set up at least one system credential provider (if no other recovery options are available; see Scenario A, below).

Scenario A

A local account user has set up a third-party credential provider and regularly uses it to log into the device. One day, the user installs some update to the device that breaks the third-party credential provider, and the user is unaware of this change before restarting the machine.

On the next restart, the user is on the logon screen and is unable to use the expected third-party credential provider. If the user has set up a system credential provider, the user will be able to log into the machine using it. If not, the user has no way to recover the account on the machine.

Scenario B

An MSA/AD/AAD account user has set up a third-party credential provider and regularly uses it to log into the device. One day, the user installs some update to the device that breaks the third -party credential provider, and the user is unaware of this change before restarting the machine.

On the next restart, the user is on the logon screen and is unable to use the expected third-party credential provider. If the user has set up a system credential provider, the user will be able to log into the machine using it. Alternatively, if the system’s password credential provider is available, the user can remotely request/reset the password and use that to log into the machine. If neither option is available, the user has no way to recover the account on the machine.

Conclusion

In summary, we want to discourage the disabling of all system credential providers on a device. While third-party credential providers may fulfill additional authentication requirements for particular groups of users, it is very important to ensure that the user can always regain access to their machine when a breaking change occurs. System credential providers provide this guarantee.

Custom credential providers

The Windows credential provider framework enables developers to create custom credential providers. When Winlogon wants to collect credentials, the Logon UI queries each credential provider for the number of credentials that it wishes to enumerate. After all providers have enumerated their tiles, the Logon UI displays them to the user. The user then interacts with a tile to supply the necessary credentials. The Logon UI submits these credentials for authentication. Credential providers can also be used by the Credential UI when credentials are necessary. See CREDENTIAL_PROVIDER_USAGE_SCENARIO for a list of scenarios where a credential provider can be supported.

Thanks to this system, it is much easier to create a credential provider than it was historically. Much of the work is handled by the combination of Winlogon, the Logon UI and the Credential UI. In order to do so, you will need to create your own implementation of ICredentialProvider and ICredentialProviderCredential. If you are implementing a V2 credential provider, which is recommended, you will also need to implement ICredentialProviderCredential2.

It is important to note that credential providers are not enforcement mechanisms. They are simply used to gather and serialize credentials, submitting them for authorization. The local authority and authentication packages will handle and any necessary security enforcement.

Combining credential providers with supported hardware, you can extend Windows to support logging on with biometric information, passwords, PINs, Smart Card certificates, or any custom authentication package you choose to create. You can customize the logon experience for the user in a variety of ways as well. For example, when the Logon UI queries your credential provider for the credential tiles, you can specify a default tile to provide a customized experience for a user. Credential providers can even be designed to support single sign on (SSO), authenticating users to a secure access point as well as machine logon.

Credential providers are registered on a Windows machine and are responsible for the following.

• Describing the credential information required for authentication.
• Handling the communication and logic with any external authentication authorities.
• Packaging the credentials for interactive and network logon.

Keep in mind that multiple credential providers can be installed on a single machine.

Wrapping credential providers

Wrapping a system credential provider can be done to add functionality to that credential provider that is not natively supported. This is not recommended because it can lead to problematic behavior. Changes can be made to the credential provider which may conflict with the wrapper causing a poor user experience or even preventing the user from getting into their device. This is especially true with the frequent update cadence of Windows 10.

If functionality in a credential provider is needed that is not included natively, the recommended path is to create a custom credential provider. This is a more stable approach that does not take dependencies on the system providers.

Windows 10 credential providers

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Asked by:

Question

We have a desktop application that modifies the user logon experience. This works fine in Windows 8 and also, barring a few minor bugs, in the last preview of Windows 10 (9926). However, I have just upgraded my 9926 build system to 10041 and now my credential provider does not work at all! Worse, the logon box is completely messed up so that so one can logon on.

Does anyone know what has changed under the covers? There is a document that describes how the credential provider interface works in Windows 8. Is there anything similar for Windows 10?

All replies

Just started looking at this. The differences that I have seen so far are that the logonui.exe can ask for some COM interfaces that don’t appear to be documented. In our filter CP we now pass them onto the Microsoft Credential Provider for processing and return them as is.

I’ve also had to implement ICredentialProviderCredentialWithFieldOptions.

I am working now, but the bit I am now stuck on is that there appears to be a new interface ICredentialProviderCredentialEvents3. It seems to have an extra method SetFieldBitmapBuffer over its inherited brothers. Can’t find any doc on it.

are there any updates on this issue? We are also seeing this problem (current build 10130).

Yes, if you download the Windows 10 SDK which is now available. There are a some new interfaces you may have to implement as well as what’s mentioned above.

Hope that helps.

Thank you, we might try that.
On the other hand, are older Credential Providers supposed to be incompatible with Windows 10? That seems harsh to me. According to https://msdn.microsoft.com/en-us/library/windows/desktop/mt158211%28v=vs.85%29.aspx, both V1 and V2 Credential Providers should be still supported.

Is this a bug in Windows 10 or is it mandatory to implement these new interfaces? If it is mandatory now, were can I find documentation for that?

Thank you again.

I take your point, but I did only say may. I haven’t found documentation for them yet other than SDK header files.

Have you considered tracking what COM interfaces you are being asked for and how you are responding to them as per my first post? Just replying that you do not support something with E_NOINTERFACE may be the issue. From memory, not all of them are Credential Provider interfaces. You may be being asked for something else. That was our biggest problem in getting up and running. I do also apologise, It has been pointed out to me we are using the previous released build at the moment to you, but I suspect it won’t make much/any difference. I’ll try and get there, but busy on another problem at the moment.

I was able to find more information about the circumstances of this bug:

— We have implemented a Credential Provider Filter that filters every Credential Provider other than itself (and optionally whitelisted ones).
— The deactivation of the Credential Provider Filter fixes the bug.
— Curious: Activating the Credential Provider Filter again and rebooting after having logged in with our Credential Provider does not lead to the bug again. Something changes after the first login. (Edit: No, that does not work every time. Curious++.)
— Using the whitelist, the bug goes away when <2135f72a-90b5-4ed3-a7f1-8bb705ac276a>is not filtered out. This is the PicturePasswordLogonProvider.

I have no idea why the PicturePasswordLogonProvider is so special.

No additional interfaces were implemented for this research, our Credential Provider still is a vanilla V1 one.

Edit: I did a reverse experiment whitelisting all Credential Providers except the PicturePasswordLogonProvider. There was no bug, so there has to be at least a second Credential Provider or combined group of Credential Providers that can fix the problem.