Code checkout fails when using a service account

[Schleyer, Tom]

Using my domain account to configure a TFS repository (v1.1.21) in a build plan is working fine. However, when attempting this with a domain service account (the account has access to both TFS and Bamboo), I get the following error (see attached for full log). I will also point out that the identity in the error log is mine, so it seems like the process is expecting me as the configured user for the repository:
java.lang.RuntimeException: com.atlassian.bamboo.repository.RepositoryException: com.microsoft.tfs.core.exceptions.TECoreException: TF14045: The identity 74b1c2c2-c073-4dff-8ccf-410fcd0f4579 is not a recognized identity.
at com.atlassian.bamboo.executor.RetryingTaskExecutor.rerun(RetryingTaskExecutor.java:141)
at com.atlassian.bamboo.executor.RetryingTaskExecutor.runTask(RetryingTaskExecutor.java:99)
at com.atlassian.bamboo.executor.RetryingTaskExecutor.retry(RetryingTaskExecutor.java:207)
at com.atlassian.bamboo.executor.RetryingTaskExecutor.retry(RetryingTaskExecutor.java:188)
at com.atlassian.bamboo.plugins.vcs.task.VcsCheckoutTask.execute(VcsCheckoutTask.java:123)
at com.atlassian.bamboo.task.TaskExecutorImpl.lambda$executeTasks$3(TaskExecutorImpl.java:319)
at com.atlassian.bamboo.task.TaskExecutorImpl.executeTaskWithPrePostActions(TaskExecutorImpl.java:252)
at com.atlassian.bamboo.task.TaskExecutorImpl.executeTasks(TaskExecutorImpl.java:319)
at com.atlassian.bamboo.task.TaskExecutorImpl.executePreparationTasks(TaskExecutorImpl.java:91)
at com.atlassian.bamboo.build.pipeline.tasks.PrepareBuildTask.call(PrepareBuildTask.java:81)
at com.atlassian.bamboo.v2.build.agent.DefaultBuildAgent.executeBuildPhase(DefaultBuildAgent.java:204)
at com.atlassian.bamboo.v2.build.agent.DefaultBuildAgent.build(DefaultBuildAgent.java:176)
at com.atlassian.bamboo.v2.build.agent.BuildAgentControllerImpl.lambda$waitAndPerformBuild$0(BuildAgentControllerImpl.java:131)
at com.atlassian.bamboo.variable.CustomVariableContextImpl.withVariableSubstitutor(CustomVariableContextImpl.java:185)
at com.atlassian.bamboo.v2.build.agent.BuildAgentControllerImpl.waitAndPerformBuild(BuildAgentControllerImpl.java:125)
at com.atlassian.bamboo.v2.build.agent.DefaultBuildAgent$1.run(DefaultBuildAgent.java:127)
at com.atlassian.bamboo.utils.BambooRunnables$1.run(BambooRunnables.java:48)
at com.atlassian.bamboo.security.ImpersonationHelper.runWith(ImpersonationHelper.java:26)
at com.atlassian.bamboo.security.ImpersonationHelper.runWithSystemAuthority(ImpersonationHelper.java:17)
at com.atlassian.bamboo.security.ImpersonationHelper$1.run(ImpersonationHelper.java:41)
at java.lang.Thread.run(Thread.java:748)

[Sergey Podobry]

Let us check that out.

[Sergey Podobry]

Unfortunately we couldn’t reproduce the issue. Here are some tips that may help:

• clear TFS cache (delete %USERPROFILE%\AppData\Local\Microsoft\Team Foundation or $HOME/.microsoft/Team Foundation folder)
• remove old TFS workspaces (you can list them with tf workspaces /collection:<url> /computer:* /owner:*) - probably the service account cannot resolve and remove your workspace

Also we have some questions:

• what TFS server version do you use?
• is the issue reproduced on another build agent?

‌

[Schleyer, Tom]

We are using TFS 2017.1 and, yes, the issue is reproducible on other agents.

[Schleyer, Tom]

Is there a cache folder on the Bamboo server (Linux) related to the TFS plugin?

[Sergey Podobry]

Yes, it’s $HOME/.microsoft/Team Foundation. By the way, did you try code checkout under the service account using tf.exe on Windows?

[Schleyer, Tom]

Hi Sergey. TF.exe works fine with the service account. Here’s some more information- I deleted the Cache folder under $HOME/.microsoft/Team Foundation/4.0, recreated the repository in the build plan (specifying the service account), but the build still fails. It continues to error with: The identity 74b1c2c2-c073-4dff-8ccf-410fcd0f4579 is not a recognized identity. Is there anywhere else on the Bamboo server where this identify might be cached?

[Sergey Podobry]

Hi Tom. That’s really strange. $HOME/.microsoft/Team Foundation/4.0 is the only cache location (btw, did you use $HOME for the account that runs a bamboo agent?).

However workspaces are stored on the TFS server. Did you check workspaces for your account and on the build machine (tf workspaces /collection:<url> /computer:* /owner:*)?

[Schleyer, Tom]

We are actually using a local build agent (on the Bamboo server). Is this fine or do you recommend a remote agent? (e.g. installed on a TFS server)

[Sergey Podobry]

No, that’s fine.

[Schleyer, Tom]

I did discover Bamboo related workspaces in TFS under my account. Once I deleted them, I no longer received the error with my related identity. I’m getting access denied messages now, but I’ll sort that out on the TFS side. Do you know what level of permissions are needed for getting a TFS plugin repository to work properly?

[Schleyer, Tom]

Well, I thought I was getting close. The service account became locked, resulting in the access denied message. Now, I’m getting the identify not recognized message again.

[Sergey Podobry]

Oh, now it’s starting to make sense! Your service account needs at least the following permissions:

• administer workspaces
• create a workspace
• read
• check out

‌

[Schleyer, Tom]

Thanks. I’ll try that.

[Schleyer, Tom]

Update- I was able to get the service account to work on a different TFS collection (source code in a different database). The service account permissions are the same between the two collections, so I don’t believe the issue is permission related. Let me know if you have any other troubleshooting ideas.

[Sergey Podobry]

This is a definitely TFS configuration issue. Are you sure that collection-level, project-level and version control permissions are the same? Try running TFSSecurity /imx <username> /collection:CollectionURL and compare them.

Also I think you can turn on TFS server logs and check them for any clues.

[Schleyer, Tom]

I ran TFSSecurity, which showed the same group memberships. However, as a test, I added the service account to the Team Foundation Administrators group, which resolved the problem. So, it does appear the permissions are not quite the same between the two collections. Possibly, the Administer Workspaces permission is not in place. I’ll see if I can track this down, but let me know if you have any other thoughts. If not, go ahead and close this ticket, as I think I have enough information now. Thanks again.

[Schleyer, Tom]

Adding the service account to the TFS group below solved all of the issues!

[TEAM FOUNDATION]Team Foundation Service Accounts

[Sergey Podobry]

Glad to hear that!