This content has been marked as final. Show 9 replies
Yes, we can do all of these.
You can't include the software pre-installed in your system image, if that is what you are asking. Each client needs to install independently, so that it gets a unique encryption key.
General Management Platform? You install the admin server on any Windows box.
Yes, you can make a standard admin account that is set on all machines.
Temporary access can be granted through challenge/response codes (which only work for that session), or just add their userID to the system and force them to synch. You can also use what I call perpetually disabled IDs, which can only be used after getting a code from a SafeBoot admin. The account will re-disable at its next synch interval.
actually you can, but you must create the image PRIOR to the client being activated (any boot code being installed etc).
not many people do this though as deployment is just a single file exe - most people install SafeBoot as part of the customization phase.
Are u able to explain this a little more?
Sounds like it may be useful to the setup we have here.
Create an unmanaged ID in SB console (no AD/LDAP bindings) uncheck the "Enabled" checkbox. You can then assign that ID as standard user for a group of machines. The user will then be added to all of those machines, but unusable by any end user, without first getting "Unlock" code from the help desk (we renamed this function on the webtools to "Temporarily Enable" because "Unlock" sounds like a password lockout). Once it is unlocked, you can give them the password and have them login with it. They do their thing... like adding another user or something, then it synchs and re-disables the account. So who cares if they wrote down the password, you can't use it anyway.
We also have a generic ID for machines that end up in the Default Machines group. This ID is enabled, but gets removed when an admin puts the registration in the correct container and resets it to the right policy.
ok i follow up to the point where the end-user requests the unlock code/temporarily enable.
At this point the PC is offline and the unmanaged ID is disabled.
Where do i get this unlock code from myself (we do not use webtools)?
And after this, the unmanaged ID is still disabled (as it cannot update from the network).
Sorry i'm a little lost. Thanks for trying to answer my questions though!
Sorry... by WebTools, I was referring to either the SBHelpDesk web page (or in our case, a custom page that makes API calls to SBADMCL). You can use the GUI Console to do the same thing...
Have remote user enter in the disabled ID (Options -> Recovery -> User Recovery -> enter 'sbhelper', or whatever), click Next, and read the code to an admin. The admin would then enter in the code from the user, click Next, select Unlock (from the code type list), click Next and read the code to the remote user. Once this is complete, the user can then login to SafeBoot with that ID and password (make sure the account can't change password and never expires). Once they have logged in, you can have them run whatever you need them to do to assign themselves to the machine. The ID will be re-disabled the next time the machine synchs to the database. Unless you change your machine settings, the machine will lock and be unusable if they are still logged in with that temporary ID when it synchs. We have addressed this by having the custom tool: add the user, synch the machine, wait 45 seconds, then reboot.
Thanks mrgui, i get you now.
I guess my immediate thoughts are, what is the difference between this and using machine recovery (boot-once)?
So far, if i need to add a user to a machine, i would get them to perform the machine boot-once recovery, add their username to the machine, and perform an online sync.
This allows the user to completely login to the system. Depending on your machine settings, a boot once could result in the user getting left at the SBGINA login and have no credentials to get past it. If the synch fails for some reason, you would have to issue an "unlock screensaver" code so they could attempt a Windows login. Sometimes we have connectivity issues and it helps if they can at least run 'ipconfig' or establish a VPN connection.
On a separate issue, I would not allow your general Help Desk to issue "Unlock Screensaver" codes. If UserA calls the help desk (verifying their identity) and gets an "unlock screensaver" code, the only information the help desk person gets back is the machine name. It would not indicate if UserB was currently logged into that machine. Once the code exchange was completed, UserA would then be using LAPTOP1 as UserB (with all of their Windows rights: shares, domain access, network access, and any domain based SSO content). If you are using the built-in SBHelpDesk, just comment out the line for that code type. If you are using a home-grown, just filter on who can execute that code type. I advise replacing the SBHelpDesk with a home-grown web page that performs all actions as a SB service account. It will result in better logging (who did what) and keeps you from granting direct SB access to the help desk. If they had SB access to generate recovery codes and SBADMCL files, they could generate other code types that you may have removed from the SBHelpDesk page.