Inherited Deny due to Access Levels

Yesterday I was building some logic against the TFS API and used impersonation to do that.

One of the things that is needed in order to allow a call to TFS to be impersonated is to give a user the “Make Requests on behalf of others” permission. This server level permission is not default and should be allowed for the user under which your custom application is running.

In my case I used a System account (service account) for this and it failed because I did not set this permission.

When setting the permission (in TFS Admin Console on server level) or with Web Access on Collection Level, I saw that the user still had a “Inherited Deny” for this action

SNAGHTML1957d5ec

I tried to find why this was the case. I tried TFSSecurity (which is documented pretty good nowadays..) and even tried the database but I could not find why this user had an inherited deny.

After a while a colleague mentioned, did you check the access levels? No….I did not.

In Web Access you can give people access to a specific group making them a Basic user, an advanced user or a Stakeholder. This has to do with licensing

Add the user or group

When I added the user to the Basic or advanced group the rights changed from “inherited deny” to “inherited allow”

Hope this helps

Advertisements

One Response to “Inherited Deny due to Access Levels”

  1. A sign that it’s an Access Level issue is that the “Inherited Deny” is written in orange. We’ve had the same kind of problem on a service account which was used for the build system…

%d bloggers like this: