The service account requires writeable access to the master database, & serveradmin & securityadmin - I think most people just give it sysadmin & live with it, but at my place of work the auditors deem this a serious issue
Full access is required the data sources on the analysis services database
The system requires a dedicated instance of reporting services
and finally, to run the administration tool, you require local admin rights to the application server!
Whilst i can't help with most of the above, I did figure a way to reduce the impact of giving end-users access to the admin tool.
1) Create local accounts on the server for each user - due to the number of rights allocated, this should be kept to a minimum. The name should match their domain username. These users should be placed in a local group called something like TFS_Admins, which we will use later
2) For each local account, set the following script as the start-up application (the environment tab of the user object)
(Example) "C:\Program Files\Microsoft Team Foundation Server 2010\Tools\runit.bat"
The script file should read as follows:
@echo off
runas /user:((DOMAIN))
You're now in a position where, if the user logs on to the server via RDP using their local server account, they will be prompted for their domain password, and (assuming they're configured as TFS admins, and their domain accounts have local admin rights) they will be thrown into the admin tool without any explorer start bar being run - Result. The RDP window will close 0-60 seconds
The next problem to tackle is that, since the users are domain admins, they can just rdp directly to the server & use their domain account.
3) Create a domain group containing the domain accounts of your TFS admins (DO NOT include those who are normal server admins!). Create a DENY ACCESS security entry on the file C:\Windows\Explorer.exe
This does 2 things. Firstly it stops the users from logging on remotely (which could also admittedly be done by adding them to the security policy "Deny log on through terminal services") but it ALSO prevents them from running explorer.exe via a backdoor, like the "open logs folder" link on the logs page of the administration console. - 2 birds, one stone. I'm sure you can see the reason for not adding server admins to this domain group!
One final issue to resolve: The locally logged-on user can still initiate the security dialog by using CTRL-ALT-END on the RDP session. This allows the ability to shut down & restart the system, and to run Task Manager from which all sorts of nefarious applications could be started - including explorer.exe - we didn't block the local users from running it.
4) DENY the TFS_Admins group created earlier access to c:\windows\system32\taskmgr.exe - again this should not contain normal local administrators
5) in the local security policy (or better still using a GPO) remove local administrators from the
"Shut down the system" and "Force shutdown from a remote system" rights. Replace them with domain admins, or potentially another local group to which your regular server operators can be added
6) Turn off default shares!
Hive: HKEY_LOCAL_MACHINE Key: SYSTEM\CurrentControlSet\Services\LanManServer\Parameters Name: AutoShareServer Data Type: REG_DWORD Value: 0
Idiot proof note: If you can't find the value in the registry under the exact location (i.e. it does not exist) - please right click in the right pane of the window and create it.
(Thanks Dan Petri)
And now you have a way to lock down the administration rights that need to be granted to TFS administrators to prevent your users mucking with the server config.
I'm sure it's not completely bulletproof, and someone somewhere will find a way in - for a start, I haven't looked at disabling remote WMI, disabling remote registry editing etc, However, it is a **** lot better than how it looks out of the box.
Enjoy.
