利用Windows的GINA（Graphical Identification and Authentication ）的机制，我们可以方便的在Windows的本机（Local）

实现自定义的认证过程。比如说SmartCard,UsbEkey认证......等.但在Windows的服务器端MS同样提供了一些机制来为我们实现

类似的功能。

以下为MSDN的文档：

Creating Custom Authentication Packages

If you are supporting a system that defines a new type of logon procedure, such as retinal scanning or voice recognition, you must create a custom authentication package to analyze the new logon data and determine whether to accept the user's credentials. You can also create new authentication packages that use standard logon data but implement new security protocols.

The LSA calls the Functions Implemented by Authentication Packages when it receives an authentication service request from a logon application. When a user attempts to log on to the system, the authentication package must check the user's logon data against the credentials information on file. The authentication packages provided with Windows store this information either in the security accounts manager (SAM) database or in the Active Directory (depending on the version and configuration of the operating system).

Windows NT, Windows 2000, or Windows XP does not permit applications that are not part of the operating system to access existing credentials data directly; to do so would create a security risk. To work around this restriction, your custom authentication package must call MSV1_0 to access the user's authentication information. Your package calls MSV1_0 to perform the initial authentication and create a logon session. If the initial authentication is successful, your package then performs additional processing to support the new logon protocol or algorithm and sends an authentication result to the LSA. In essence, your custom authentication package wraps MSV1_0, extending its functionality to support the new logon protocol. This following illustration shows this process.

Both the custom authentication package and MSV1_0 support the authentication package interface (see Functions Implemented by Authentication Packages). The LSA calls the authentication package interface functions in the custom package which, in turn, call the functions in MSV1_0. The custom package must be able to pass the incoming logon information using data structures supported by MSV1_0. In addition, the structures passed to MSV1_0 should be allocated in the address space of the logon process, not the LSA address space.

The MSV1_0 package processes the authentication request and returns a result (and if successful, an LUID) to the custom package. The custom package can then perform additional authentication checks, such as deciding whether the scanned-in fingerprint matches the user account, and return an authentication success or failure back to the LSA. If your custom package revokes a logon allowed by MSV1_0, it must delete the logon session created by MSV1_0 by calling the DeleteLogonSession function.

最后如下注册：

Registering Subauthentication Packages

Each Subauthentication DLL is assigned a DLL number in the range 0 through 255. The DLL number is used to associate the subsystem calling LsaLogonUser with the appropriate Subauthentication DLL. DLL number 0 is reserved for the Domain Controller SubAuthentication Filter. This DLL allows the package to do additional password or logon validation on a domain controller in addition to that normally done by the MSV1_0 or Kerberos packages. DLL numbers 1 through 127 are reserved Microsoft DLL numbers. Numbers 128 through 254 are available to independent software vendors. Software vendors can be assigned a DLL number by Microsoft by sending e-mail to subauth@microsoft.com. Registering a subauthentication package with Microsoft prevents conflict between package IDs when multiple subauthentication packages are installed on a system.

Microsoft will not assign the value of 255 for any subauthentication DLL. If you are developing a subauthentication DLL for use only within your company or facility, subauthentication number 255 is recommended. In this case, it is not necessary to obtain a subauthentication DLL number from Microsoft.

After you have a DLL number, you can register the DLL under the related authentication package's registry key.

The registry location for MSV1_0 subauthentication packages is:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0

The registry location for Kerberos subauthentication packages is:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos

If the required key does not exist, you must create it. Under that key, create a registry value named 'AuthN' where 'N' is the DLL number (for example, Auth255).

The 'AuthN' registry value holds REG_SZ data and must specify the name of the subauthentication package DLL. The DLL must be in the default DLL load path.

The authentication package loads the named DLL the first time the subauthentication package is requested

据我的经验，如果你还你没有得到MS的正式NUMBER,请用"0"即Auth0。

更多的信息参考PlatformSDK的文档