Symantec Encryption disable pre boot authentication non domain PC's

[Migration User]

Ref http://www.symantec.com/business/support/index?page=content&id=TECH153865

I have SEE 8.2 deployed and about 50 devices are not domain joined.  The article indicates to use a GPO to disable PBA for users or before upgrades.  How do I disable the PBA by editing the registry for x amount of boots or permanently change the setting on devices which do not get GPO's?  To push a new client version I also need to suppress the PBA for 1-2 restarts so both installers can complete from a batch file.

Is there a reg key I can set?

Thanks.

[SMLatCST]

All non-domain linked clients, if installed with a managed SEE client, will drop into the "SEE Unassigned" Native Group in the SEE Manager Console (have a rummage around the left pane to find it).

As long as these computers are managed you will be able to remotely set a policy to either disable pre-boot authentication altogther, or configure time windows or periods when it is not required.

To do so, you'll also have to create a new SEE Native Policy (usually near the top of the left-pane) which either disables Authentication altogether, or configures Auto-Logon.

Native Policies are explained in more detail in the Policy Administrator Guide (see attached)

Attachment(s)

SEE-FD 8.2.0 Policy Administrator Guide.pdf   2.57 MB 1 version

[Migration User]

We have some clients on the domain and some off.  Both have software pushed from Microsoft System Center or Symantec SEP.  What we need to achieve, including the update of the SEE product itself which requires a reboot because it is two installers, is the ability to;

• With the user logged out and gone home push the software to the device.
• Install the first part of the software which could be the framework for the new SEE or a multipart application which installs a component, reboots then installs part two such as Office upgrades.
• Set a registry key if possible so the next reboot is automatic without the user requiring to enter credentials in the PBA screen.  These are done as needed to various computers so we do not want to apply a GPO unless needed and are not sure until the day on which machines will update.
• After it boots the install process can complete without the user interaction and the registry key is removed or reset so users once again are prompted for login at the PBA screen.

I am sure the GPO in the SEEM does something.  What are the registry values to use so we can apply them as part of the application upgrade "temporarily".  Again out of 400 computers on one day we may pick groups of them to upgrade.  That upgrade fails when the reboot does not complete the process as the PBA screen halts the process.

Bitlocker has a "suspend" registry key which can be toggled to allow the software updates, even an OS upgrade can be done which when complete the key is cleared.  Drive stays encrypted but is allowed to auto boot so the process can complete.  Then normal prompts return for the users.

Thanks again.

[SMLatCST]

SEE too, includes options for supressing PBA to allow patching and other software updates.  These are managed via the AutoLogon tool, included in the installation media, but under a separate directory (SEE-AU):

http://www.symantec.com/docs/TECH151755

http://www.symantec.com/docs/DOC5567

[Migration User]

Our SEPM is 8.2.  About 250 of our 500 laptops are still not 8.2.  Various levels of 7.0.3 to 7.0.8.  When we use the autologon tool to create a msi to call first for the upgrade to SEE 8.x it will not run because the framework on those clients is less than 8.0 which we are upgrading.  So in effect we cannot use the tool to bypass SEE if it is in the 7.0.x range.  Requires framework 8.0 is the message.  Tells me that if the SEE is not continually upgraded with each release things get more complicated as more versions get deployed.

As for deploying software, again we have the issue.  We need to check using our System Center to see if the laptop is at least 8.0 SEE first then run the PBA MSI we create.  If the laptop is less than SEE 8.0 we are back to being stuck at the boot prompt in the middle of the install as the PBA msi fails to run on framework less than 8.0.

If there was just a reg key we could set before pushing an app called "SuppressPBA" with a value of "1" or higher that decreases until 0 at each boot everything would be fine, or at least better.  Or if the autologon utility could go back a few more versions of SEE.

Thanks.

 

 

 

[SMLatCST]

...did you happen to go through the documentation for the AutoLogon utility?

When this is installed to the SEE Manager Console it adds additional policy options to both the "SEE Native" Policies and the GPO policy options for SEE.

Have you tried these policy options?  The AutoLogon MSI is not the only option.

[Migration User]

I can work around some of the domain joined laptops with a GPO.  It is difficult to set a GPO for a specific date and time for SEE to have the policy set and allow the PBA skip when we are not sure when the devices will be on the domain by the users.  We need to set a really long time window such as 30 days.

As indicated in my original post "change the setting on devices which do not get GPO's" many of my clients which are not at 8.0 are the ones which are deployed off the domain.  The ones on the domain can use the GPO but those are mostly updated to 8.2 already as we have direct access to them.  The MSI only works on 8.0 or higher.

System Center can push upgrades to those remote clients without being in the domain which is great.  This is where a reg key may help as the GPOs are not applicable.  However the MSI has limits too.

If the skip PBA was part of the install for the framework it may help with SEE updates.  Might need to look at that for the SEE upgrades at least.  Other installers like Office which auto reboots at the end to complete the process are an issue.  We use SSO also with SEE and when the laptop reboots after an Office update the user who logs into SEE usually is restricted (non admin) at the desktop and it appears to fail the completion of the upgrade.  Again we are thinking the skip of the PBA for the one boot may help and allow the installer to complete.

Thanks. 

[SMLatCST]

...it'll be best if we recap a few things.

First off, we'll recap the PBA bypass options:

Permanent Bypass - this can be accomplished by disabling the requirement for users to authenticate to SEE

Temporary Bypass - this is accomplished using the AutoLogon Utility, and can also be used to schedule recurring time windows when PBA will be skipped (e.g. every Wednesday morning between 3am and 5am for 3 reboots).

Ad-hoc Bypass - this is something we've not touched on yet, and is performed using the SEE Reboot Utility (also available in the media under a SEE-RU directory).  This is an SEE executable that reboots a Windows machine and bypasses the PBA on that one reboot.

As far as how to apply these options, please see the below:

Both the Permanent and Temporary Bypass options can be managed via policies.  The GPO policy option is used for domain integrated endpoints.  The SEE Native policy option is used for endpoints that are not on the domain, but are installed with a managed SEE client (and can contact the SEE Management Server).

The Ad-hoc option must be run locally on the encrypted endpoint (usually from a command prompt).  This can be scripted, but I would recommended against doing so.

Finally, something else worth noting, is that it is possible to upgrade the SEE-Framework Client, SEE-Full Disk and SEE-Removable Storage all in one go, and only reboot at the end.

I hope that helps!