I'm trying to setup a release definition on TFS but I'm running into an access denied message:
I thought I should have this permission, since I am part of the "Agent Pool Administrator" group:
I noticed however, that my queue has no roles, and that I can't add one for some reason, which I suspect to be the related to the problem:
My question is how do I correctly configure the permissions? I've already googled a bunch but I still couldn't pinpoint what exact permission I'm missing.
[[Update]]
This is TFS 2015 update 3
Apparently, I am myself a project collection administrator already, but still don't have queue permissions and don't know, or can't see where to add myself as a queue admin.
The said queue was created by me, but indirectly, I created the agent pool with the auto-provision queues checked, and that created the queue, however, if I try to directly create a queue, I run into another "Access Denied" error
[Update]
Trying to run tfssecurity /collection:http://wada-pc:8080/tfs/DefaultCollection /g+ "[Agent Queues]\Agent Queue Administrators" "domain\account"
Leads me into Error: Access Denied: Eduardo Wada needs the following permission(s) to perform this action: Edit collection-level information
However, I should have that permisison:
Yes, your issue is related to the agent queue roles. An agent queue provides access to a pool of agents. Usually, there are two groups under the Roles:
Agent Queue Administrators: People in this group can register new agents in that pool, add users to the Agent Pool Service Accounts and add other administrators to the pool.
Agent Queue Users: For Team Foundation Server the service account you specify for the agent (commonly Network Service) is automatically added when you register the agent.
Try to use the account that create this agent queue to check whether it can see the roles, and add your account into the two groups.
Or, try to create a new agent queue to see whether you can see the roles, and deploy a new agent.
Related
TFS 2018u1. I have a custom Powershell task that calls TFS services via the VSSConnection object:
$VSS = Get-VssConnection -TaskContext $distributedTaskContext
$Client = $VSS.GetClient(...)
Question: what kind of security context does the task get? It's definitely not the agent account. To make sure, I've set up a temporary agent instance that runs as me, the TFS admin, and the custom task running on that agent doesn't have the full admin.
The underlying problem is - I'm trying to get the current agent record from a task, and the task only sees one pool, even though we have several. See this answer.
I'm trying to get the current agent record from a task, and the task only sees one pool, even though we have several.
There is a Agent pool security roles concept, for example with Administrator Role, you can:
Rregister or unregister agents from the pool and manage membership
for all pools, as well as view and create pools. They can also use the agent pool when creating an agent queue in a team project. The
system automatically adds the user that created the pool to the
Administrator role for that pool.
The default rights of a build agent running a release task should be the same as build service account. Please add your build service account to Agent pool security roles to Administrator from the collection-level admin context, Agent Pools page. Then try it again.
Another possibility you are lacking of vso.agentpools scope in your customize release task.
Grants the ability to view tasks, pools, queues, agents, and
currently running or recently completed jobs for agents
More details please take a look at Supported scopes
First off, the distributedTaskContext doesn't connect to TFS with NTLM, like Patrick Lu's answer suggests. It connects with Authorization:Bearer and a token. I've used the same token to invoke the /_api/_common/GetUserProfile endpoint, which returns the current user, and got back the following identity record:
{
"IdentityType": "user",
"FriendlyDisplayName": "Project Collection Build Service (TEAM FOUNDATION)",
"DisplayName": "Project Collection Build Service (TEAM FOUNDATION)",
"SubHeader": "Build\\233e4ccc-d129-4ba4-9c5b-ea82c7ae1d15",
"TeamFoundationId": "7a3195ee-870e-4151-ba58-1e522732086c",
"EntityId": "vss.ds.v1.ims.user.7a3195ee870e4151ba581e522732086c",
"Errors": [],
"Warnings": [],
"Domain": "Build",
"AccountName": "233e4ccc-d129-4ba4-9c5b-ea82c7ae1d15",
"IsWindowsUser": false,
"MailAddress": ""
}
It looks like some kind of artificial identity that TFS creates just for this purpose. Looking in the TFS database in the tbl_Identity table, there are numerous user records with names like that - one per collection, it seems, and also some that are project specific.
This user belongs to a server-level group called "Security Service Group" (and also to a collection level group with the same name). Those groups belong, respectively, to Team Foundation Valid Users and Project Collection Valid Users and nothing else.
At least on the collection level, the "Security Service Group" is visible and contains a lot of accounts.
All those "Build Service" users belong to the domain called "Build". A domain is not a security principal though, you can't grant rights to a domain.
Speaking of OAuth scopes. I've used the same token to invoke the homegrown "what are this token's scopes" page, and it turns out the distributedTaskContext token has exactly one - app_token. It's a valid scope that opens up all endpoints and all methods (see the dynamic scope list). The scopes parameter in the extension manifest has no bearing on that; it only affects the client-side contributions.
When it comes to pool visibility, though, the story is tricky. Seems like all the "Project Collection Build Service" accounts belong to Valid Users, but granting the Reader role on all pools to Valid Users doesn't open them up to the REST API in tasks. Granting Reader explicitly to "Project Collection Build Service" does. However, there are numerous accounts like this (one per collection, it seems) - and granting Reader only opens the pools up to release definitions in the collection where it resides. In order to let tasks in releases in all collections read the pools, you need to go through all collections and grant Reader to the "Project Collection Build Service" from each.
We would like to have a process which runs a script that forces an Active Sync of TFS (the Active Directory TFS sync job ordinarily only runs once an hour). Based on my understanding of this post (which discusses using a command line program to accomplish the same end result), the calling account would need to have the Queue Background Jobs TFS permission granted.
Without this permission attempting to execute the PowerShell script, I receive the following error:
Exception calling "QueueJobNow" with "2" argument(s): "Access Denied: Smith, Jane needs the following permission(s) on the
resource AllJobs to perform this action: Queue background jobs"
It is not clear how one would grant the Queue Background Jobs permission. It does not appear to be in the TFS Console or GUI anywhere.
This permission is granted via the tfsecurity command. You will need to grant the Job namespace Queue and Read permissions as depicted below in order for the PowerShell script referenced in the question to work:
To see current security assignments:
tfssecurity /acl job /server:https://myserver/tfs
To grant a user read job information:
tfssecurity /a+ Job AllJobs Read n:mydomain\myuser ALLOW /server:https://myserver/tfs
To remove a user’s read job information:
tfssecurity /a- Job AllJobs Read n:mydomain\myuser ALLOW /server:https://myserver/tfs
To grant a user queue job access:
tfssecurity /a+ Job AllJobs Queue n:mydomain\myuser ALLOW /server:https://myserver/tfs
To remove a user’s queue job access:
tfssecurity /a- Job AllJobs Queuen:mydomain\myuser ALLOW /server:https://myserver/tfs
I've got an issue with Jenkins 2.6-1.1 running on CentOS v7.2.1511. I am using the Crowd 2 integration plugin v.1.8 and the Matrix Authorization Strategy plugin v.1.3.2 for authentication and authorization, respectively. Security is configured for "Project-based Matrix authorization strategy".
In my Jenkins configuration, I employ two group assignments on the Crowd server: jenkins-administrators and jenkins-users. jenkins-admininstrators has every permission enabled. jenkins-users have permission to:
Overall: Read, RunScripts
Agent: Build, Configure, Connect, Create
Job: Build, Cancel, Configure, Create, Delete, Discover, Read, Workspace
Run: Delete, Update
View: Configure, Create, Read
SCM
jenkins-administrators obviously have all of these permissions enabled as well.
The issue is that, at some point, users who are in both jenkins-administrators and jenkins-users ceased having the ability to configure nodes or create new nodes. What I mean by this is that, when the user clicks on the link to configure a node, or clicks OK on the new node (/computer/node) page, the post goes through, but a page is never returned.
If I remove the user from the jenkins-administrators group, they are able to add and configure nodes as expected.
If I configure the user such that they are in the jenkins-admininstrators group solely, they are unable to login (which seems like it could be related).
I tried modifying the security matrix so that jenkins-administrators and jenkins-users had the same configuration in re: to nodes, but this didn't change anything.
Outside of the slave logs, and the occasional message to /var/log/messages, there doesn't appear to be anything relevant in /var/log/jenkins/jenkins.log.
Any suggestions on how I can configure Jenkins logging to show me information that is more relevant to node configuration and creation, or any suggestions in general on how I might observe the node creation and configuration process?
My environment: Windows 7 Pro SP1
I created a private queue and am trying to send messages to that queue using an ASP.net MVC application. I get the error: MessageQueueException "The queue does not exist or you do not have sufficient permissions to perform the operation"
I've verified, in code, that the queue exists before attempting to send a message. I've given full-control to the queue for "EVERYONE" and "ANONYMOUS LOGON" using the queue properties' security tab.
I've looked at the existing threads and haven't found a solution yet.
Thank you.
I have created a WCF service using the NetMsmq binding for which i created a private queue on my machine and executed the project. This works fine as such and my WCF service is started and accesses the message using the queue in the debugging environment. Now, I wanted to host the service using the windows service and for the same I created a new project and windows installer as well (This service runs under Local System Account). Then I tried installing this windows service using the InstallUtil command through the command prompt. When installation is happening and during the service host opening, I get an exception saying:
There was an error opening the queue. Ensure that MSMQ is installed and running, the queue exists and has proper authorization to be read from. The inner exception may contain additional information.
Inner Exception System.ServiceModel.MsmqException: An error occurred while opening the queue:Access is denied. (-1072824283, 0xc00e0025). The message cannot be sent or received from the queue. Ensure that MSMQ is installed and running. Also ensure that the queue is available to open with the required access mode and authorization.
at System.ServiceModel.Channels.MsmqQueue.OpenQueue()
at System.ServiceModel.Channels.MsmqQueue.GetHandle()
at System.ServiceModel.Channels.MsmqQueue.SupportsAccessMode(String formatName, Int32 accessType, MsmqException& msmqException)
Could anyone suggest the possible solution for the above issue? Am I missing any permissions to be set for the queue as well as the windows service, if so could you suggest where should these permissions be added?
Tom Hollander had a great three-part blog series on using MSMQ from WCF - well worth checking out!
MSMQ, WCF and IIS: Getting them to play nice (Part 1)
MSMQ, WCF and IIS: Getting them to play nice (Part 2)
MSMQ, WCF and IIS: Getting them to play nice (Part 3)
Maybe you'll find the solution to your problem mentioned somewhere!
Yes, it looks like a permissions issue.
Right click on your private queue from the Server Manager, and select Properties. Proceed to the Security tab, and make sure you have the right permissions in there for your Local System Account.
This is also confirmed in Nicholas Allen's article: Diagnosing Common Queue Errors, where the author defines the error code 0xC00E0025 as a permissions problem.
I ran into same problem, here is the solution.
Right click "My Computer" --> Manage. In Computer Management window go to "Services and Applications --> Message Queueing --> ur queue", select ur queue and access properties. Add the user running ur WCF application and give full access. This should solve the issue.
Can simple be that the service can't find the it's queue.
The queue name must exact match the endpoint address.
Example:
net.msmq://localhost/private/wf.listener_srv/service.svc
points to local queue
private$\wf.listener_srv\service.svc
If queue name and endpoint are according to each other, then is most like that the credentials defined on the IIS pool don't grant access to the queue.