Just create at user called $AutoBoot$ and add the user to the machine or the machine group. Remember to uncheck "Disable checking for AutoBoot" on the machine.
The AutoBoot password has to be 12345
I have created a $AutoBoot$ user. The user is added to a machine group. And i can see in the client log that the user is added and updated token. The password by the way is aslo reseted to default, wich always is 12345.
This should make the machine to bypass the boot protection screen? I did some restarts just to try and it stops on the boot protection screen. Do i have to login with the autoboot user?
I unchecked "disable checking for autoboot"
Seriosly i dont get it, what do i miss?
A long time ago i created a $autoboot$ user that i tried to use at this point. For some reason it didnt work.
I created a new User unchecked Force sync... And i put down another password synced out the file and user to a test machine. And it reboots without any problem.
This thread can be closed.
don't forget by using AutoBoot you stored the auth key on the disk itself, so you are no longer very secure at all. There's a section in the Device Encryption Administrators Guide which discusses this, and also in the product click-through license.
The release notes in one of the 5x versions notes the ability to change the password, I believe.
Also, another thin you can do is allow local autoboot control (whatever the check-box is). With this, you could customize your other applications (if they require a reboot) to issue C:\program files\safeboot\sbadmcl -command:disablesecurity (after app install finishes), then reboot. That would allow for a single reboot, but not always auto-load the keys for the encrypted machine. Once the system comes back up, it synchs and removes the autoboot setting.
You could also set it as a machine shutdown script for your workstations or a SMS package that runs on every connect. If at all possible, this should be applied to specific machines for short duration, and only when absolutely needed.
NOTE: These settings do reduce the security surrounding the drive encryption software. These settings should not be globally set without first getting management approval or you may be out of a job (or sitting with your CISO in jail).
For anyone using DisableSecurity as part of a script, I've found that if you synch after you DisableSecurity that the AutoBoot user is deleted. While the chances are probably slim that a synch will occur between the time I DisableSecurity and the time the reboot actually takes place (seconds), over the course of many installations across thousands of computers, the likeliness increases. To avoid this, I usually usually use SbAdmCl to ForceSync before I DisableSecurity. It increases the traffic over the WAN, but when I'm pushing down 200-300mb applications globally, the 7kb audit upload is would barely be noticeable.
disablesecurity creates a fake local $autoboot$ user, so of course, when you sync if this account is not allocated to the machine for real, the policy system will remove it from the local machine.
if you want it to stick, set the real $autoboot$ user to the machine.
How unsecure are we talking? If I have the Autoboot user bypass the first login, my drive is still encrypted correct? Is the drive vulnerable for the second or two?
The whole spectrum of possible attacks opens up when Windows OS is running. Even at logon screen. You get there easily with autoboot. Without it, you cannot start OS that would have access to your disk data. Unless you know credentials or have SDB key.