CredentialProvider

The activate value tells when our credential provider should tell the caller that we want to be auto selected by default. Usually the caller just ignores this, but sometimes this works. We can only suggest, the caller decides.

You can limit the number of certificates that are used by specifying a matching condition.

You can limit the number of tokens that are used. The value is a bitmask of those tokens that are allowed. Default is all token types accepted.

It is possible to enable or disable auto logon. Auto logon is possible when single sign-on is active and the token is opened. Usually, you do not want to use auto logon for Windows Logon. Locking the desktop will then auto logon again.

The credential provider will usually replace another credential provider, so the original credential provider needs to be blocked. Each provider is identified by a GUID, so you need to specify the list of GUID:s that should be blocked. Separate them using a semicolon.

CommandLink controls how to show an extra dialog for CredentialProvider.

CommandSelect controls how to show the dialog for CredentialProvider.

The credential provider has three different purposes and they can be controlled separately.

To allow for conditions we have added a whitelist/blacklist to specify when they should be enabled.

This entry forces a PIN change for Credential Provider. It is used together with PinExpire key.

Two different versions, or generations, of credential providers are available. The second generation added the possibility to group credential tiles, only used by Windows Logon. This does not work well with smart cards with multiple certificates, so it should be avoided.

Windows Logon can be done with certificates without an UPN, depending on your Windows configuration. The default setting is disabled, so those certificates should usually be ignored.

The grouping of tiles used for second generation credential providers will require matching of the certificate UPN to get the right user identifier. This search can be done with two different modes.

The loading of credential providers is asynchronous, so you may want to start the loading of the available certificates directly at the initial call. Currently, the loading is so fast that this parameter will not make a difference.

Any certificate can be used to logon to Windows, but you can specify that the Microsoft logon enhanced key usage is set in the certificate.

Our credential provider can show all empty smart card readers as empty credential tiles, or a single empty credential.

Our credential provider can show all available certificates as a credential or only the first available certificate.

Our credential provider can remove unnecessary values from the credential information returned, that is, the smart card name or the smart card reader name. This ensures that the caller does not know which smart card or smart card reader was used. This makes the unable to disturb anything they do not know anything about.

The grouping of tiles used for second generation credential providers will require matching of the certificate UPN to get the right user identifier. But in which group should the unknown credentials be located?

Normally nothing will be shown when no smart card reader and no credentials are present. Use this parameter to add an extra empty tile when nothing is present.

For the returned credential the PIN value is usually protected to avoid reading. This is not required and may be turned off for diagnostic purposes.

Our credential provider can run in full mode or pass through mode. The full mode completely replaces an existing provider. In pass through mode the exiting provider is called to create the returned credential blob.

Our credential provider can remember the last used credential and select that credential as default next time our credential provider is used. Reference to credentials is stored in the local configuration, see example below.

This value only tells which of our credentials that we consider to be default by those returned from us. Microsoft have their own selection rules to tell which actual credential that will be default.

When our credential provider is running in Terminal Server environment, we can be called to update a credential sent from the client. This allows for single sign-on-experience when used in pre-auth scenarios. This parameter is used to enable this translation.

When update remote is active, this parameter tells if our credential provider should block itself when it fails to translate the credential.

When update remote is active, this parameter tells if our credential provider should block itself when all values are successfully translated and auto logon will be possible.

When update remote is active, this parameter tells if our credential provider should register all available certificates to current desktop. Certificate used as credential will always be registered.

When update remote is active, this parameter tells if our credential provider should translate the credential using only the username. Translation with username/domain will be run first.

When update remote is active, this parameter tells if our credential provider should translate the credential using username/domain.

When update remote is active, this parameter tells if it should use any certificate that currently is on a logged-on token. Last used certificate is checked first.

When update remote is active, this parameter tells if it should use the last certificate that is on a logged-on token.

When update remote is active, this parameter tells if it should use the only available certificate that is on a currently logged-on token.

When our credential provider is wrapping another credential provider it must know which field is used for which purpose. The values usually never change and it is intended to be used only by the development team. Thus, no documentation is available.