Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Occasionally, we need to allow 3rd party software tech support into our servers. We've had a few issues with our on-site IT staff not monitoring the sessions and the 3rd party rebooting servers.

Does anyone have official policies in place within their organization for appropriate responsibilities and/or conduct of the IT staff when allowing tech support to remote into a machine? What is allowed/disallowed? What protocols should be followed?

Thank you, John

share|improve this question

4 Answers 4

up vote 0 down vote accepted

We do have a policy for 3rd party server access. We disallow it, unless they own the hardware and we have it isolated to its own network segment. The policy actually reads:

"No third party shall access any [company] owned server resources without an IT representative facilitating the connection."

The procedure is a little more complicated. We typically set up a remote (Webex) session and transfer control so that they can access the system, and IT staff can monitor as needed. It's too hard to even keep tabs on what the IT staff has done when problems arise to allow an external vendor to meddle in the systems without 1:1 supervision. It also gives our team the ability to question any bizarre compromises that the 3rd parties make to install additional apps, disable the AV or monitoring, or worse.

Round that out with a tripwire or configuration management tool like Ecora Auditor (what we use for Tier 1 systems), and you should be in very good shape. This gives us a periodic delta file of what has changed across a huge cross-section of configurations on servers.

share|improve this answer

We do not allow 3rd party vendors to take control of sessions. If required, they can view the session whilst WE click the buttons.

It's actually a sackable offence here to allow 3rd party vendors to take control.

share|improve this answer
    
This is the way I do it, too. –  womble Oct 27 '09 at 19:01

I would recommend the following:

  1. That you leave the user account that the third party uses disabled and require them to call you to notify you that they need access. You can then enable the account for their use.

  2. When they are logged in they should be required to allow you to shadow their session. You can do this easily if they're using RDP to connect. If not, you can look at something like LogMeIn, GoToMeeting, etc. to facilitate their ability to connect and your ability to monitor\shadow their actions.

  3. You should take control of and be the authority when it comes to installation, modification, reboots, etc. You are the last word when it comes to "owning" the server.

  4. It should be your policy that one of your staff members is required to monitor\shadow the session and document anything that needs to be documented.

At the end of the day, you're responsible for the uptime, security, stability, reliability, etc. of the server. Vendors are only interested in getting their stuff to work, by any means possible.

share|improve this answer

Depending on who the 3rd Party is and what they need to do we have in the past allowed full access. Providing some details to the 3rd Party regarding the production status of the server also helps. We've never had any problems. If you run into issues though you can always remove rights from the account the 3rd Party is using to prohibit them from rebooting, etc. or failing that you can shadow their session on the server.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.