Domain admin rights for 3rd party support

Associate
Joined
12 Oct 2004
Posts
1,432
Location
Aberdeen, Scotland
Hi all, wanted to get some thoughts from you on what permissions I should configure for a 3rd party IT support company for a remote office.

I'm placing a new remote DC out in a branch office of ours who have their own 3rd party IT support. Network/Server design etc. will still be managed by myself, but I will need to give this 3rd party company access to certain functions on the server in order for them to perform their function. I've never had to deal with the complexities of splitting up permissions for other admins before as I work in a very small team with equal access, so I'd really like some advice on how to approach this.

We are a mostly server 2003/2008 domain, the server that will be supported is basically just a remote DC/GC, DNS, DHCP, file and print server. The 3rd party will be responsible for monthly physical site checks which includes server and desktop hardware and ensuring smooth running of backup tapes etc. They'll also be required to join computers to domain and troubleshoot desktop user issues (when the issues are local).

Any advice appreciated as always chaps.
 
I have the same sort of setup where I work.

Our 3rd party has a series of elevated accounts for general day to day stuff and a dedicated domain admin account that only the high level engineers there have access to. The company we use are very good and we have had zero issues with them in the 3 years they have been helping with domain administration. They do everything from manage our VPN to complete domain redesigns to user level support.

Drop me a mail in trust if you want to know more about the company we use.
 
Thanks, we've already got a contract in place with a decent company though, pretty happy with them, but I still want to lock down and control their access.

I've been playing around with this for a few days now and still having some difficulty, I'm either assigning too much or too little access.

Basically I want them to be able to have essentially local admin access, the main problem there is that this server is a domain controller so setting that up isn't possible and I really want to avoid having to set every little permission individually. They primarily need to be able to maintain server hardware, check server backups and perform restores etc., maintain and manage files and folders as an admin (although changing domain security/permissions etc. should be prohibited), install/manage windows and hardware firemware updates, restart standard services and reboot the server when needed.

For example, I want them to be able to open up services.msc and restart/start/stop services etc., to do this it looks like permission has to be set for each individual service through a GPO. What a ballache.

Any bright ideas guys?
 
Last edited:
It's not too dissimilar to what we do at our office, e.g desktop support have full admin rights over desktops in their office, but not on any servers

You don't need to grant them domain admin rights. It'd make things a lot more simple if you can keep them away from the domain controller etc..

I presume you'll be "isolating" them within their own OU, if so delegate access to them & use a GPO to give the appropriate permission over desktop machines

What will the 3rd party need to perform on the server?
 
Thanks for the reply, yeah, I definitely want to avoid giving them domain admin rights, which is why I'm going through this bother.

However, I definitely need to give them a level of access to login to this domain controller, we have contracted them to perform:
  • Hardware maintenance
  • Administer and maintain all backups on the server hence they will need full read/write access to files/folders on the server
  • Manage the print server role
  • Restart services etc. as well as be able to reboot/shutdown the server
  • Join computers to the domain and have all necessary rights for desktop support

So far I've added them to the backup operators built-in role, allowed them to rights to log in to the server over terminal services, and added the option for joining computers to the domain under delegate services.

I'm really not sure how to achieve the rest of what I need though...
 
Last edited:
I can't think of anyway of mass adjusting the permissions for the services

Is there any way you can get another server (worst case a pc) in the branch office. If so I'd consider moving all the domain controller & dns functionality to a separate box & look after that yourself

DHCP, print services, file storage (e.g. client services) & backups can be left on the non DC then and you can delegate local admin rights to the server, client pc's etc...
 
BattFink has probably suggested the cleanest way of doing it, but there is obviously cost involved for licensing and additional hardware if you aren't already virtualising.

Alternatively, in the past we've used lsrunase which allows you to carry out a runas, but with the password encrypted. So you could just set them up a batch file to run services.msc, for instance, but as a domain admin - without them being able to see the password.
We last used it on XP, so I can't say if it'll work for you on a 2003 or 2008 server.
 
Ugh, thanks for telling me what I didn't want to hear guys! ;) Thanks though.

The thought of separating the DC had crossed my mind too, but really as this has just been put into production, it'll be too much effort (and weekend work) to change it now, so I think I'll just have to suck eggs and give them some elevated admin rights. I'll just put this down to experience for the next time as this is going to become the template for a few of our other remote offices.

I've added them to the administrators built-in role, and I'm going to see how they get on with that. At least this way it stops them from logging into any of our other global servers, although they could just give themselves the domain admin permission, but I'll just have to be blunt with them and give a level of trust. That and turn on detailed logging and watch them like a hawk for a while... :) We're a paranoid lot us IT guys, eh?
 
Back
Top Bottom