In case you’re wondering, yes I specifically included the TFS update number because the licensing for TFS changes so often these days, that you really do have to be know what version of TFS someone is talking about to be sure you’re telling them the right thing. Anyway, I work with a lot of customers who get really confused about TFS Access Levels, in terms of what they mean and how you know who belongs in each “bucket”. You may even be thinking “what are access levels?” depending on what version of TFS you are running today. Access levels were introduced with the release of TFS 2012, to ensure that users of the TFS web tools were only accessing the features they paid for. You can find the access levels administration page in your TFS admin console, at the TFS instance level (so make sure you are in the Control Panel and not at a lower level, like at the Collection or Team project levels).
You may have noticed (default) in the Full Access level row, this means that if you do not EXPLICITLY assign anyone to an access level, they will get Full access by default. Not a big deal on my personal TFS instance because I have Visual Studio Ultimate and am the only user. On your own instance however, best to leave the default at Limited, and add Active Directory groups to each Access Level to give your TFS users the right level of functionality, based on their licensing. Otherwise you risk unintentionally giving people access to features they have not paid for, being out of compliance with Microsoft, and having very unhappy users when you later have to fix things and end up taking away your TFS user’s features because they haven’t paid for them. There unfortunately isn’t obvious documentation on how this works for TFS 2013 so you may not have even realized that’s what was happening, but I did find reference to it in the TFS 2012 docs.
Now your next question is probably “What features does each access level give you?”
3) With Limited access, users can create and modify only those work items that the user creates and can query on their own work items only.
This list only applies to on-premise TFS, access to web features on VSOnline are slightly different these days, and access is controlled by your license level automatically since you have to sign in with your MSDN account or Live ID. Note the major differences between each level, since this may even influence what license you decide to buy for your users. Most people fall under at least Standard access, but your QA, developer, and support teams often require a Full license for Web-based test management and the feedback tools. If you’re not familiar with them, definitely look up some videos and watch them in action, or reach out to me for a quick demo! :)
OK, so now you understand where to set access levels, and how they control what a user has access to on the web. How does each access level map to a license? This is pretty simple actually.
You may be wondering, “well what about Visual Studio Professional?”. Yeah, not sure why they left that one out, but since VS Pro includes a CAL, those users would get Standard access. Note that this means that VS Pro users do NOT get access to some really cool features listed above.
Now what about security? It’s very possible that your Active Directory groups are currently mapped to a user’s role, and does not necessarily coincide with access levels. Particularly if your developer group has a mix of VS Pro, Premium, and Ultimate. Now you cannot just assign your TFS_Developers group (or whatever you call it) to one access level, since some fall under Standard and some fall under Full. My advice is to create 3 Active Directory groups that map to your 3 access levels and chuck people into those AD groups as you buy or renew your licenses with Microsoft. Technically, you could set one Access level as the default, not create an AD group for it, and anyone “unassigned” to an access level gets the default. I avoid that because it assumes too much, and that is how users fall through the cracks. Just create Active Directory groups for each level, assign that AD group to the corresponding level, and whenever you add new TFS users they get added to that access level AD group to allow them access to the right TFS web features.
Hopefully this shed some light on how Access levels work, and does not further confuse you. TFS licensing is rather complex, but sitting down and planning out your security and access model, and leveraging Active Directory as much as possible can make this really simple to administer in the long run. You can also find out more about licensing from the Visual Studio and MSDN Licensing White Paper, it’s honestly a blog series in and of itself, and again it is so complex and changes often enough that I’m not even going to try to untangle it just yet.