With Windows's Gina (Graphical Identification and Authentication) mechanism, we can be convenient to Windows's native (local)
Implement a custom authentication process. For example, SmartCard, USBekey Certification ..., etc., but in Windows server-side MS also provides some mechanisms to implement us
Similar features.
The following is the documentation of 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 ............. ..
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 last registered as follows:
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 Subaulthentication Packages IS:
HKEY_LOCAL_MACHINE / SYSTEM / CURRENTCONTROLSET / CONTROL / LSA / MSV1_0
The Registry Location for Kerberos Subault Health 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 SubaulthenThe DLL. The DLL Must Be in The Default Dll Load path.
The Authentication Package Loads The named DLL The First Time The Subault Health Package Is Requested
According to my experience, if you still haven't got the official Number of MS, use "0", acth0.
More information Reference PlatformSDK documentation
