Thursday, December 13, 2007
Setting Deployment Server Security
For those of you out there that manage the same Altiris Deployment Servers (DS) that you use, disregard this. For those of you out there that have someone else manage your physical servers, this may be of interest to you when it comes to using the Role and Scope security options in DS. There is a DS utility located at C:\Program Files\Altiris\eXpress\Deployment Server\TechSup\Windows\DSDBSecurity.exe. Even if a user is a full dbo of the eXpress database, they are also members of the public role. The default denies in the public role will restrict access to those users. Only System Admins (members of the local administrators group as an example) will cancel out the public deny permissions. The public deny permissions need to be removed on certain stored procedures in order for the Role and Scope security to work properly,hence the use of the DSDBSecurity.exe tool. I found this out the hard way when working on a DS6.5 server after spending part of the day setting up the role and scope security options for the jobs and computers after importing a bunch of active directory groups and assigning them the appropriate roles for my organization. I believe that there is an Altiris KB article that references the use of the tool, but I thought I would bring this out in the open to stress the use of the tool if you should decide to turn on the security options in DS. The other item that I wanted to address deals with a software piracy issue that I noticed recently. Most organizations have some type of a software repository that software is installed to the eventual end-user that requested the software to begin with. Besides the options of using NTFS permissions on the share to block unwanted users from accessing the software folders, you can implement some simple security options to minimize the possibility of software piracy (your simple end-user copying the terabyte of software from you servers onto his own computer for personal use). The use of hidden shares always comes to mind as I am a believer of the coined phrase 'They can't hurt what they can't see". One of the other easy ways to 'Lock Down' your software is to modify the MSI files that you use for software deployment by adding a runtime option that requires the MSI to run with an additional command line parameter. For example, you could use a command line option such as SOFTWAREKEY=12345678. You could generate a random hash against the MSI you are deploying and use that random number as your software key variable above. So, when deploying the software, you could call the variable like this, msiexec /i \\myserver\mysoftwareshare\mymsi.msi /qn SOFTWAREKEY=12345678. The MSI will only install if you know what the command line variable SOFWAREKEY number that is actually embedded inside the MSI. If someone tried to run the MSI without the SOFTWAREKEY command line and correct number it references, the MSI will fail. These are just some easy ways of locking down your software repository and minimizing your risk of software piracy.