When creating a LAP, keep in mind the following implementation issues:

• Often LAPs require a fallback mechanism. For example, in the case of a fingerprint LAP, there is often an ability to enter a strong password if the fingerprint recognition engine fails. Such mechanisms are LAP-dependent, and must be implemented in the LAP itself. When LASS makes the following calls, a global LASS lock is held. As a result, LAPs should not block any longer than necessary when implementing these calls:
  
  
  • VerifyUserStart
    
    
  • VerifyUserStop
    
    
  • VerifyUserwith VU_NO_UI flag set
    
    
  • LAPCancelVerifySequence
    
    
• If a LAP spawns a new thread, the newly created thread should not make any calls back into LASS. If it does, it is possible to cause a deadlock.
  
  
• When you implement a LAP, it is important to consider what the behavior should be when VerifyUseris called before the user has been enrolled. The two recommended behaviors are:
  
  
  • VerifyUserreturns TRUEuntil the user enrolls.
    
    
  • Enrollment is forced on the first call to VerifyUser.
    
    
  The default password LAP implements the first option.
  
  
• When implementing the LAP-exported function LAPCancelVerifySequence, it is important to ensure the function always returns a failure whenever the LAP has determined the verification was unsuccessful
  
  
• LAP must use the startup flag for all windows.
  
  All dialogs and other windows used in a LAP must have the WS_EX_ABOVESTARTUP flag set in the window's EXSTYLE. This flag is defined in \public\shellw\oak\inc\wpcpriv.h. An enrollment window must have this flag if you are going to show it while the device is locked. For information on setting this style, see GWL_EXSTYLE in SetWindowLong.
  
  
• On devices with phone capabilities, LAP must enable emergency calls and DTMF.
  
  To determine if a device has phone capabilities, you should query the registry key HKLM\System\State\Phone. The "Status" value will have bit 32 set if a phone is present. You should use the defined names for the registry value in \public\ossvcs\sdk\inc\snapi.h:
  
  
  • SN_PHONERADIOPRESENT_ROOT
    
    
  • SN_PHONERADIOPRESENT_PATH
    
    
  • SN_PHONERADIOPRESENT_VALUE
    
    
  • SN_PHONERADIOPRESENT_BITMASK
    
    
  To recognize when an emergency number is entered, you can use SHGetEmergencyCallList.
  
  To place calls, you can use PhoneMakeCall.
  
  To send DTMF tones during the call, you should post the WM_CPROG_SEND_VKEY_DTMF message to the CProg window. The CProg window can be found by looking for a window with class "MSCprog". The message is defined in \public\shellw\oak\inc\wpcpriv.h. The WPARAM for the message should be a TCHAR representing the DTMF character.
  
  If you implement LAPDisplayCodewordor LAPLockoutUser, emergency dialing must also be available from those functions.
  
  
• LAP must set the lock timeout in the registry.
  
  You must provide a way for the user to set the lock timeout. To enable the timeout, set values in the registry key HKLM\Comm\Security\LASSD\AE\{50C13377-C66D-400C-889E-C316FC4AB374}. The REG_AE_AUTH_FREQ_TYPE value must be set to FT_Minutes_Idle to turn the timeout on, or FT_Every_FV to turn the timeout off. The REG_AE_AUTH_FREQ_VALUE should be set to the number of minutes until timeout. These values are defined in \public\common\sdk\inc\lass.h. For more information, see Setting an AE Policy.
  
  You should show consideration for the timeout policies. You can find these policies in the registry key HKLM\Comm\Security\Policy\LASSD\AE\{50C13377-C66D-400C-889E-C316FC4AB374}. The same values are used in the same way to define the policy. If the timeout policy is type FT_Minutes_Idle, the policy is enforced and the user should not be allowed to change the timeout. You should only read the policies and not modify them.
  
  
• LAP should broadcast a WM_SETTINGS message when changing the timeout.
  
  To notify the device that timeout settings have changed, the you must call PostMessage(HWND_BROADCAST, WM_SETTINGCHANGE, 0, 0).
  
  
• LAP should implement a timer on VerifyUser (LAP)to prevent accidental attempts and emergency calls.
  
  You should use a timer to cancel verification or clear any entered information after a period of idle time. This prevents random keypresses from accidentally dialing emergency phone numbers, and prevents accidental authentication attempts.
  
  If you implement LAPDisplayCodewordor LAPLockoutUser, you should also use a timer to clear the entered information after a period of idle time.
  
  The LAP may check for the "PasswordTimeout" value in the HKEY_LOCAL_MACHINE\Security\Policies\Shellregistry key to use for this timer.
  
  
• LAP should implement a mechanism in LAPCreateEnrollmentConfigDialogto prevent this dialog from staying up unnecessarily.
  
  This prevents a user from leaving the enrollment window open and a malicious user entering new authentication data when the user is not paying attention.
  
  
• LAP should have a way to force enrollment if the auth required policy is set.
  
  
• LAP can implement its own policies and policy listener.
  
  You can implement additional policies that are unique to your authentication mechanism. The sample password LAP uses "MinimumPasswordLength" and "ComplexElements" policies to set constraints on the password set by the user. A picture LAP could choose to have a policy that determines the picture file to be used for authentication. Policies can be set by IT Administrators. In this example, if the policy is not set the user can choose the picture to use. If the policy is set, this option would be disabled during enrollment and the user would not have a choice. Policies pertaining to a specific LAP should be set in the registry under HKLM\Comm\Security\Policy\LASSDinside a key specific to the LAP.
  
  

When you add LAP-specific policies, you may want to use State and Notifications Broker APIs to register for change notifications if the LAP needs to take immediate action when a policy changes.

To force enrollment if the auth required policy is set: The "Password Required Policy" (Security Policy ID 4131) determines if a user must be enrolled for authentication on the device. When this policy changes, LASS will unload and reload the active LAP. When necessary, the LAP can call SHDeviceLockAndPromptto lock the device and allow the LAP to force enrollment. For more information on strong passwords, see Guidelines for Creating Strong Passwords. For more information on LAP Implementation Issues, see State and Notifications Broker.

Password Enrollment Screen

Remarks