1. During permissions testing .... always make sure that at least 2 of TFS admins are full admins on the TFS server and in the TFS security settings.
2. Define the security groups you want for TFS.
3. Create these groups as Windows groups on the server that's running TFS.
4. Create corresponding TFS server groups for these Windows groups and assign one member (i.e. the Windows group) to each of these TFS server groups (see first 2 snapshots).
5. Create team project security groups and by default assign TFS server groups as members of these groups (see 3rd snapshot).
6. Assign security permissions by team project security group at the Team Project level or at the Area levels.
7. On the Windows server, assign roles/permissions for SQL Server Reporting Services that correspond to the Windows Server groups you've created.
8. On the Windows server, assign roles/permissions for Windows SharePoint Services that correspond to the Windows Server groups you've created.
9. Remember to "keep it simple". Think of having a handful of Windows server groups that correspond 1:1 with TFS server groups that in turn correspond 1:1 with Team Project groups. Then in turn these Team Project groups have all the team project level and areas' security permissions based back on those Windows server groups as the standard. Anything else should be thought of as an exception. What this will do is handle the cascading of all permissions for SharePoint, SQL Server Reporting Services and TFS throughout all the services associated with TFS/SharePoint.
Warning: It can be disastrous to NOT "keep it simple". And keep in mind that this article assumes you are running a single server solution with all the databases and web front ends on the same Windows server.
Friday, February 27, 2009
Subscribe to:
Post Comments (Atom)
Thanks for sharing, I will bookmark and be back again
ReplyDeleteemail security service