Windows custom credential provider

In windows default credential provider, there is a link of "More Choices" on taking a RDP connection as shown in below image. For eg: Windows V2 credential provider holds 25 field descriptors and in this we are not able to get "More Choices" command link. Is it so that this field is not handled by windows credential provider? If so, kindly provide details for handling this use case. Each evolution in authentication technology places a greater burden on the abstraction layer between the core Windows credentialing engine and the GUI that must prompt the user in a certain way.

For example, the pictorial cues and screen real estate required to prompt the user to type in a password are different than those required to prompt the user to place a finger on a fingerprint reader.

At the same time, Microsoft needs to provide as consistent an experience as possible so that users don't get confused. In addition, the Windows logon process winlogon.

One core requirement of that effort was to move plug-ins out of the winlogon process space to the fullest extent possible. That requirement was born of reliability concerns. If, for example, a poorly written GINA is loaded into the winlogon. And even if GINA could have been adapted to run out of process, there would still be the issue that it wasn't designed to provide a consistent, controlled experience across arbitrarily complex, interactive credential-gathering scenarios.

While I believe that my design for the hybrid credential provider, in tandem with the significant level of code reuse I achieved in the implementation, meets the requirements I laid out earlier, there are aspects of the implementation that prevent the provider from being deployment-ready in its current state. I've already discussed one such shortcoming-data should be read from the smart card asynchronously.

Now I'll discuss the remaining opportunities I see for improvement in decreasing order of severity. First, the user credential is not being stored securely on the smart card. Ideally, reading the card-based file that stores the user password should only be possible after supplying the correct PIN. However, a limitation in the current card module interface makes that difficult to implement.

Namely, the set of predefined card file access conditions does not include such a "user-only read" option. I suppose it is poetic justice that, having been involved in the card module design decisions that led to this limitation, I'm now inconvenienced by it!

I hope the product team will extend the card module interface in a subsequent version. In the meantime, the smart card password file ought to be encrypted in such a way that, if the card is stolen, the PIN is required in order to decrypt the password. An RSA key pair, created and stored on the card, would suffice, but rather than using the RSA public key to encrypt the password file directly, cryptographic best-practice advises you to use a symmetric key and algorithm, such as Advanced Encryption Standard AES.

The RSA key would instead encrypt the symmetric key. To round out the design for an encrypted password file, you could modify the existing password file format to include the associated encrypted key.

If you go this route, be sure to consider the versioning challenges that come with committing to a crypto algorithm and key size. Assume that the algorithm you choose will get hacked some day. Also, the design as discussed thus far doesn't include a cryptographically secure data integrity check. That might seem like a minor point, since an attacker theoretically needs to know the PIN in order to modify anything on the card.

But I would consider such a feature to be a necessary aspect of defense-in-depth. The second limitation of the current implementation is that it only supports a single credential per card.

Take a look at the ScHelp. This performs a simple deserialization of the password file, which was presumably read from the card. The credential-parsing logic as a whole will only handle a single credential per card. However, some users may require multiple distinct domain credentials to get their work done. Would you extend the provider to support that, or would you issue those users multiple cards?

The former increases implementation complexity while the latter increases deployment management complexity. Again, refer to Figure 8. Assume that an attacker can create an evil smart card and insert it into workstations on your network.

At the application level, the primary mitigation against this threat is to ensure that no assumptions are made about the validity of data read from the card-don't assume that the embedded character counts are correct and don't assume that the strings are well-formed. Simply check that the element count at the beginning of every string doesn't exceed the length of the unparsed portion of the credential, and check that the true length of any string doesn't exceed the buffer allocated for it.

The last limitation I want to discuss in the current hybrid credential provider is that only one smart card reader per machine is supported. For example, if I boot a system with two smart card readers attached, each with a smart card inserted, and each card initialized with a different credential, which card takes precedence will depend on the order in which the readers are enumerated by the smart card subsystem.

It's clear that the struct only supports a single credential; a simple array or singly linked list could be introduced to enhance it. Unfortunately, this doesn't support unlock scenarios. As I mentioned, testing my credential provider was a relatively painless process. Regarding my testing strategy, I knew that I wanted to be able to attach a user-mode debugger to LogonUI in order to have maximum flexibility, both for live debugging of my sample code and for generating the tracing information I discussed earlier.

I also knew that since LogonUI runs as system and that the interactive logon scenario I was targeting is accessible only from the secure desktop, writing a simple self-contained test program to exercise the various credential provider COM interfaces would be a wise use of time.

Nevertheless, because of my background with the technology, I decided to skip writing a test program and instead proceeded with live debugging. But I don't recommend this approach. Since I didn't write a test program, I had placed additional pressure on myself to get a robust debugging environment set up. Unless you frequently do kernel-mode development, getting this kernel debugger-based test environment properly configured can be frustrating.

At a high-level, here's the preferred way of doing this. First, set up two machines in a standard kernel debugging configuration. One should be a reliable development system the debugger , the other the Windows Vista test system the debuggee.

They should be connected via serial cable. Don't neglect to configure the debuggee with a safe boot partition with Windows XP loaded. Configuration specifically, getting the two machines to talk to each other via serial cable can take some trial and error.

What's the best way to test the serial connection? On both machines, point the program to the serial port you're using and select the data rate you'll be passing to the debugger. If the characters you type into one machine's HyperTerminal window echo on the other machine, you're finished.

If not, try another serial port, connection speed, or cable. To describe the second reason for configuring a safe boot, I need to skip forward slightly. If you find that the credential provider under test causes the host LogonUI process to die or deadlock, then you won't be able to log into Windows Vista any more. This happened to me with my initial build configuration for HybridCredProv. I was using the redistributable msvcr My first mistake was that I forgot to copy that binary into the system32 directory of the debuggee.

However, that only prevented my credential provider from being loaded. The next reboot back into Windows Vista left me confused. In the debugger, I found that the msvcr Rather than drill into this, I modified the build configuration of HybridCredProv.

In summary, a safe boot partition provides a useful option for fixing configuration problems during credential provider testing. Back to the debugging configuration. The next step is to install the latest debugger package from Microsoft the one that includes ntsd. Install the public debug symbols for Windows Vista.

A full local copy of the symbols is recommended for the debuggee. Take the desired the. Starting to build your own credential provider. Credential Providers in Windows Credential Provider Technical Reference Overview of variables, functions, and architecture of the sample Credential Provider code. About This guide is to help with the initial build and set up of the Microsoft sample code of credential providers Resources Readme.

Releases No releases published. Packages 0 No packages published. You signed in with another tab or window. Reload to refresh your session. I am trying it on Windows Thanks, Shan. Tuesday, June 11, AM. Hi, ShanCh You can't avoid the further authentication when you use custom credential provide.

Wednesday, June 12, AM. Thanks Strive. Thursday, July 18, AM.