Go into the properties of the machine or of the group that the machine is in (based on how you want to administer and setup users), go to users, click Add, select the group the user is in, select the user in the right pane, and click OK or ADD. The user will now show up in the users list.
If you are looking for a way to automate user assignment to machines, you will need to do a little custom scripting for that. We use AutoIT to build compiled tools for users to assign others to their machine. Since they can only assign an ID that exists in the SafeBoot database, we aren't too worried about it getting out of control. Also, they can't do anything with the added ID, unless they know their password, so they can't impersonate either.
As far as initial user lists, part of our machine setup process prompts the installer for a user ID. They set this and it populates a text file that is read by a post-installer utility to set that user(s) to the newly created machine object.
The reason we use AutoIT is because it builds encrypted executables, so we don't have to worry about having admin credentials in plain text scripts. You could also use encrypted VB, C, etc. If you pursue this path, be sure to only grant this SafeBoot service account the required privileges, not level 32 god access.
Actually there's a function in the scripting API which lets you obscure your creds - you use adminauth instead of adminpwd, and use the command generateadminauth to create the string from your password.
That way you don't need to disclose the actual password in the script itself.
when this script is discovered, a troublemaker could then run something more sinister (with a quick search on the internet for syntax) sbadmcl -command:resetpassword -adminuser:sbsvc -adminauth:475492e3 -userusanVictim
This is another reason to severely limit the allowed functions of any service account. Admin Level: highest normal user level +1 (may not be necessary, but definitely keep it under your admin accounts) User: allow administration (to login to database) Machine: view, update, add, rename (maybe)
I guess this is the core problem of unattended admin - you want it to have permission to do things, but not permission to do the same things...
Another nice trick is to group limit the account, it stops someone using it to enumerate other things in the db. I also know customers who store their creds in a separate network repository which the worker scripts go to when they need login details - that way they can change them daily (again, via a script).
most scripts are working over the network anyway, so if there's no network access there's no point them running.
did you write your script from the ground up, or did you base it on the AutoDomain sample?
Built from ground up. We started fresh to make sure that it fit our environment and ran some sanity checks before performing the operation. Like when we first rolled out, we needed to discover what users currently use the machine and inherit them for SafeBoot. Our script enumerated the folders under C:\Documents and Settings, looking for properly formatted login names (based on our standards). It then added these to the SB registration for that machine. We perform the same verification when adding a user later.
The task of user provisiniong (assigning certain users to certain machines) has been the most pressing issue most customers ask us engineers. This can be done by manually editing the machine properties (as mentioned previously). However, this is not an automated solution. The way to automate it is to leverage our API. The McAfee Endpoint Encryption product (formerly SafeBoot) comes with an API, so anyone could write a script to automate this task. We even provide examples. In order to work, the API files would have to be deployed to the endpoint. These are sbadmcl.exe (for batch files), SbAdmCom.dll, and SbAdmDll.dll.
The script logic is usually something like this... 1. Find the username for the currently logged in user 2. Feed this username to the CreateUser SafeBoot command (this step can be skipped if all users are already in the database) 3. Find the machinename for the endpoint (check to see if it exists in the database, it if doesn't then create it with the CreateMachine command) 4. Run the SetUser command to add the user found in step 1 to the machinename found in step 3
All API calls are described in our SBADMCL Scripting Guide PDF.
This script can be run at any time, but it is best run after the SafeBoot install but before the reboot. The easiest way to achieve this is to compile the script as an exe and then include it with the SafeBoot install set as a post-install helper executable.
A future release of the product will eliminate the need for this scripting because similar functionality will simply be built-in by default. Until then, our Systems Engineers can implement a best-practice version of the script (AutoDomain) as part of consulting services.
I am creating a VBScript similar to the one described above to be run when PC's are imaged. The script will do the following:
1. get the username for the currently logged in user and the Machine name 2. Feed this username to the CreateUser SafeBoot command. 3. Run the CreateMachine command with the machine name found in step 1. 4. Run the SetUser command to add the user found in step 1 to the machine created in step 3.
My question is what happens if the PC is re-imaged?
Machine name is VistaMachine1 User to be assigned is VistaUser1. New PC is imaged for the first time. My VBScript runs at Image time: -Creates the User account in DB "VistaUser1" -Creates the Machine account in DB "VistaMachine1" -Assigns "VistaUser1" to the Users list of "VistaMachine1"
The machine then needs to be re-imaged. Engineer re-images the machine and the MachineName is the same ("Vistamachine1"). My VBScript runs again at Image time: -Script finds the "VistaUser1" user account already exists and does nothing. -Script finds the "Vistamachine1" machine account already exists and does nothing -Script finds "VistaUser1" is already present in the Users list of "VistaMachine1" and does nothing.
In the above scenario is a new machine account created by the installer? If so what happens to the old account? And what happens to the assigned users? Are they carried over to the new machine account?
Is there a better way of handling it? Should my script perform a DeleteMachine prior to the CreateMachine command?