1976

AutoBoot logic flow for token-protected KFs:

 

AutoBoot logic flow for token-protected KeyFiles:

IF KF.protectedByToken

make sure either PWD or KF_PIN exists and not empty (otherwise give up AB)

IF KF.protectedByPhone

IF PWD not empty

         use PWD as APW

ELSE

use KF_PIN

FI

ELSE IF KF_PIN exists

use KF_PIN

ELSE

use PWD as APW

FI

FI

Keyfile protection types and AutoBoot settings recognized by pre-boot (according to Thi’s opinion)

where:

+  - cred exists;
-   - cred doesn’t exist;
x  - cred is ignored



 

Note: ways of setting up AutoBoot @ SES

We kind of figure the following ways AutoBoot can be set up by SES:

• set up a specific AutoBoot user, and then assign this to client (as permanent AutoBoot ) (Note: The option to protect this user with token is greyed out on UI)
• push down remote command to enable non-permanent AutoBoot )
  • with or without the particular user specified

Note:
We don’t find where AutoBoot can be set up from the client deployment process.
Note:
TEMP AutoBoot is the internal logic used by client deployment, which is not considered here.
Note: Make sure the autoboot.ini / SDJob.bat is saved in unicode format.

To make it work AutoBoot should be set up with the following:

• Keyfile with no APW and normal token password OR
• Keyfile with APW and APW.

The decision is to not treat AutoBoot password attribute as APW even if token protected KeyFile has APW feature. Additional reason to apply this logic is that using token password requires physical presence of token (secure login) whereas using APW will allow to login the system without physical presence of token which is not secure.

APW stands for alternate password

Source of this information is Jira case SD-44523