Admin Security for Support Staff
by Dana Daugherty
Security is probably one of the least exciting points of any system but arguably one of the most important. If implemented properly SMS may be a real power tool for your admin tasks. Improper security planning could be too restrictive for your support staff to help you. Worse yet, lax security with this system could damage the trust of your end user population, or even jeopardize your job. In this article I'm going to share my SMS 2.0 security experience. Security is probably one of the least exciting points of any system but arguably one of the most important. If implemented properly SMS may be a real power tool for your admin tasks. Improper security planning could be too restrictive for your support staff to help you. Worse yet, lax security with this system could damage the trust of your end user population, or even jeopardize your job. In this article I'm going to share my SMS 2.0 security experience.
Security is always a balancing act. Within SMS this balancing act involves the ability of IT support staff to perform daily tasks, privacy of end users and administrative overhead (that's you). SMS 2.0 gives IT staff the ability to "rule with an Iron hand" or give end users the ability to call almost all the shots. Example: Remote control settings can be configured to ask the end user if they want to be remote controlled by "IT support machine name". On the opposite end of the spectrum IT staff could RC an end user in a completely covert manner, even connect and just watch them work (big brother).
As with any major system implementation get your boss on board. The way your end user population perceives this system is extremely important, especially if this is your organization's first experience with SMS. If you bring your security plan to your supervisor asking for his/her input you can buy yourself some safety.
My company includes 1500 users at 10 sites world wide. 9 of our sites have IT staff. Our NT security groups include one Global group for each of our geographic sites (xxxIT) and one NT admin account per geographic site (xxxITAdmin). The NT admin account is added the xxxIT group as well.
It seemed most logical to me to apply most of the rights that I planned to grant my support staff to the xxxIT Global groups. This plan allows me to grant rights to each IT site support staff for their own region while restricting their rights to other regions. I gave the NT admin account in each region additional rights beyond the site support group, one of which is the ability to remote control machines in other regions.
Take a look at the security model below.
*xxx = 3 character sites code also happens to coincide with our geographic regional site and the nearest airport to that site. eg SFO (San Francisco)
Site Configuration- xxxIT -(r)
All xxx Win Systems
sub) All xxx Workstations xxxIT - (r, mod, del res, rc) (r)
All xxx Servers xxxITAdmin- (rc)
All xxx Win systems- xxxIT (r) (c)
All xxx Workstaions xxxIT (r, m)
All xxx Servers xxxIT (r)
Individual User Accounts ( )
Individual User Accounts ( )
As you can see by my "graphic" (loosely used), my site support staff does not have the ability to send advertisements or create packages. At this point these functions are performed at the central site (by me) and pushed out to the other sites. This avoids having each site "recreate the wheel". By restricting the advertisements and package distribution to a small group proper testing and documentation can be performed. Also it reduces the "whoops I just sent out the wrong program to 500 users mistakes".
I'm not saying that this plan is the only way to go for you. I found it to work pretty well in my situation. My point is this, consider the points that I covered above, make a plan for your organization, talk it over with your supervisor and then implement it.
Dana Daugherty, MCSE