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
Related
I'm trying to trigger a job from one Jenkins (A) on another one (B). I've installed 2 plugins:
Parameterized Remote Trigger
Build Token Root
My issue is, that I'm able to trigger build on Jenkins (B) using for example curl and token only, which means the Build Token Root plugin is working as expected, but Parameterized Remote Trigger seems to don't respect this.
I probably should mention that I've tried different auth options, Trust All certs, etc.
My Jenkins (A) config:
Logs are the same with and without Build Token Root support enabled.
Logs I'm getting:
I was able to get this working by allowing Anonymous users Overall Read and Job Read access. It appears this is necessary because the Parameterized Remote Trigger plugin attempts to call additional APIs apart from just the /build and /buildWithParameters and those calls are the ones that fail.
It makes sense that, in order to have the default blocking capability, you need to call additional APIs to poll, but even setting blockBuildUntilComplete : false did not fix the issue. Considering that Parameterized Remote Trigger plugin plainly says it "plays well" with the Build Token plugin in its documentation, it really is not an easy feat to make them work together.
In my opinion, using the two together isn't an ideal solution because of the necessity for allowing unauthenticated users to browse your jenkins instance via the ui - I suspect you could (although I haven't tried it) get an API Token for a user with only Overall Read and Job Read access instead of giving all Anonymous Users the rights, but this includes the overhead of managing a user and an API Token, which defeats our primary motivation to use the Build Token plugin in the first place.
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.
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.
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?
We have LDAP login setup for user login and execute jobs. how to monitor users activities for the jobs that a particular user executed.
So far the only way I have seen is to go each job's console output and look for "Started by user". Is there any other way I can list all users with the jobs they executed?
Thanks
you can use this plugin https://wiki.jenkins-ci.org/display/JENKINS/Build+User+Vars+Plugin,
and adopt your build configuration.