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 experience

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)

Instance           
           
           
Collection-

Site Configuration- 
           
           
xxxIT -(r)

Collections-

All xxx Win Systems           
                       
                       
                       

sub)      All
xxx Workstations   
           
xxxIT – (r, mod, del res, rc)
           
(r)

           
All xxx Servers
           
xxxITAdmin- (rc)

Query-
All xxx Win systems-          
           
xxxIT (r)                   
           
           
(c)

All xxx Workstaions    
           
           
xxxIT (r, m)

All xxx Servers                        
           
xxxIT (r)

                       
                       
           
xxxITAdmin                
           
           
(r)

Site Status-

                       
                       
           
XxxIT                         
           
           
(r)

Advertisements-          

                       
                       
           
Individual User Accounts         
           
(  )

Packages-       
                       
           

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.

Good Luck,

Dana Daugherty, MCSE