1972

Where an Administrator sends down a command to remotely Auto-boot a device and chooses a user account that normally relies upon a token (e.g. Mobile Device-based authentication via Bluetooth or Network), once the device gets to the SecureDoc Credential Provider login for Windows, it will not permit that user (or any user relying on Mobile Device-based Bluetooth/network-based authentication) to authenticate at SecureDoc Credential Provider.  Instead, the SecureDoc Credential Provider screen will keep re-loading, and the authorization request will not be sent to (nor appear) on the user's mobile device. 

NOTE: This is a very unusual scenario, in that in normal use a device will not be remotely autobooted so that users can subsequently log on to the machine at SecureDoc Credential provider; it is primarily done so that the administrator can push software changes or updates onto the device using software deployment tools, after which the device is remotely shut down. 

Solution: Utilize only accounts that rely on a Password to perform remote auto-boot; never use any User Key File that has been converted to using a token.   The ideal is to create and use a specialized key file not associated with any users.  
Remote autoboot is not intended to be a means to force a device to boot past Pre-Boot so that users can log in - it is used so that the administrator can push software changes or updates onto the device using software deployment tools, after which the device is remotely shut down. 

This problem was encountered in the following scenario: 
1. A package is deployed to an endpoint device that specified use of Bluetooth Low Energy authentication, with an alternate password and SecureDoc Credential Provider authentication at Windows. 

In this scenario the account used was an on-Premises user AD user account
2. At some point, this user had converted to use of a Phone (Bluetooth) token for this account, and has set an alternate password. 

3. The SES Administrator sends a command to activate "Active auto-boot", selecting this user's account/key file to be used for auto-booting the device and setting a password to be used. (NOTE: this is an unusual, non-recommended use of this account). 

The command defines that the device will auto-boot: 1 time (in this example). 

4. The client device communicates with server.  ??? Click "Authorize" on phone > Command executed  ~2:57 PM

5. Turn off then on client > Active autoboot works, BL does NOT show

6. If a User at this point tries to login to SecureDoc Credential Provider using Bluetooth, one might expect that a request for authorization would be sent to the user's Mobile Device via Bluetooth...
However, in actuality the SecureDoc Credential Provider screen will keep loading, and the authorization request is NOT sent for approval to the user's Phone device. 

Solution: As mentioned above, the normal use of temporary remotely-applied autoboot sent by the Administrator is not intended to be a means to force a device to boot past Pre-Boot so that users can log in. It is primarily done so that the administrator can push software changes or updates onto the device using software deployment tools, after which the device is remotely shut down. 

If needing to use remotely-activated Auto-Boot, WinMagic's best-practice recommendation is to:
1)  Place onto the device a special account/Key File (e.g. name "tempautoboot", "remoteautoboot" or similar) whose password is stored in the SES database but nobody knows it (not even the Administrator), and said account should not permit password change and should not rely upon any form of Token-based authentication.  The Administrator can send an autoboot key file for this account using the password stored in the database. 
2) Maintain the policy to only use Administrator-triggered remote/temporary autoboot to be used for sending software changes into the device and avoid the temptation to auto-boot devices so that users can subsequently log in.
3) Never use a user account that relies upon Bluetooth Low Energy-based device authentication as the account to be used for remote/temporary autoboot.