We have TFS 2013 setup on our own server in house. We have about 8 windows users from AD that currently use it.
I need to interact with TFS via API from a console app that will run on a different server. I have it all working fine when running as my own Windows account. How can I set up a user in TFS that will be used only for API interaction? I searched around and it seems I can't add a non-Windows user to TFS for this. Is it possible to use a service account or something? What is the best practice for this?
Thanks.
No, there is not any API related service account. You could take a look at this thread: Service Accounts for Team Foundation Server
Which include a table shows all the service accounts that you might use in a deployment of TFS such as TFSService, TFSBuild...
As a workaround, you could create a public domain account in TFS used for API related. However it's not able to restrict the account only used for API interaction. Since for which permissions are needed for an end user/domain user to call into the TFS API, this is based on the action that you request through TFS API. For example if your TFS API is used for checking in files, API account need code related permission, used for triggering a build, then the API account need build related permission. More information of permission, please refer to: Permission reference for Team Foundation Server
Related
What would I need to do in terms of setup and configuration if I want to build an API that I plan to deploy and host on a virtual machine in azure. That Web Api would make calls to our on premise TFS instance to perform continuous integration processes such as creating, getting, and kicking off builds and releases? Do I need a token, some special permission, etc..
You can use TFS REST API and use Personal Access Token (PAT) to authorize. When defining PAT you can decide scope based on the request that you are going to make.
Also you may try build and release integration for DevTest labs: https://marketplace.visualstudio.com/items?itemName=ms-azuredevtestlabs.tasks
Our SharePoint environment uses Claims Based Authentication - using
FBA for external users and AD for internal users.
I have not been able to connect using default credentials or Windows
authentication to a test SharePoint site using the SharePoint Client
Side Object Model (CSOM). I am able to connect using an FBA user but
require connecting using default credentials (assuming this is the
app pool id tied to the SharePoint application) or at least an AD
account.
The message I get when executing ClientContext.ExecuteQuery is - Cannot Contact Site at the Specified URL. I
have researched this extensively and have tried numerous suggestions including the following:
Using an event handler tied to the clientContext.ExecutingWebRequest
which adds to the WebRequest headers. Solution found here
https://social.technet.microsoft.com/Forums/office/en-US/16cd0e26-8f3b-4ef2-bac4-c2c59849ab96/authentication-in-clientcontext-in-sharepoint-2010?forum=sharepointdevelopmentprevious.
Using System.Net.CredentialCache.DefaultCredentials
Using System.Net.NetworkCredential passing in AD account
Thanks for any ideas or suggestions.
Tom
I should have mentioned that we are using SharePoint 2010 and that I'm trying to retrieve and update user profile properties. As I was beginning to code a solution to do this (using my FBA connected ClientContext), I read that in SharePoint 2010, you can only update user properties using the UserGroup web service. I get an Access Denied when trying to connect via the web service. I believe the ClientContext sits on top of the web services so the scenario/issue is the same. Again, any thoughts or suggestions are greatly appreciated.
Well, after much research, it seems that there is a solution. Adding a header to the request programmatically is the first step. The only issue is that in addition to adding the header, you must add an additional Windows authentication zone to SharePoint. I do not want to add another zone to our production environment.
Since the program I'm putting together accesses SharePoint and non-SharePoint databases, I would like to run it on a non-SharePoint server so I will most likely use an FBA account that is specifically created for this purpose.
In case anyone is interested, here is another link explaining how to add the header to the web request. You will receive an error - Object Moved without adding an additional zone. Here is a link which describes adding a zone.
Here's the scenario
3rd Party App, with a back end. Customer uses the app.
Back end needs to access user's exchange information, assumedly via EWS
Back end is running in our datacenter/cloud, not customers.
Cannot require local administrator involvement
Want to avoid storing username/password in our back end.
Want to support both Office365 and on-premise.
I believe this is currently impossible, but wanted to verify:
Impersonation would be a great way, but requires Administrator
Token based authentication is not used for this. It is for a mail app to use for SSO to the backend, not for the backend to access Exchange.
OAUTH would be ideal, but is a) for Office365 only currently b) requires a portion of the back end to be hosted by Azure c) The Azure install has to be linked to the Office365 install and is for the local administrator only.
Is my analysis correct? Any options I've missed?
You're mostly correct. OAuth is currently for Office 365 only, so that would rule out on-premise. However, with OAuth you do not have to host your back-end in Azure. You would need an Azure tenant to register your application, but the app itself is not required to be hosted in Azure. If you use EWS, then even with OAuth you will need some admin involvement, because EWS requires a permission scope that requires the app to be registered in the target tenant, users can't consent using a registration from another tenant.
If you use the REST APIs, which are in preview, you wouldn't need an admin's involvement, users could consent for themselves. That would get you almost where you want to be (assuming the REST APIs provide the data that you're after), but wouldn't support on-premise.
So to add to this mostly correct answer from Jason:
using pure rest, you need only create a "multitenant" application and users can self-consent.
You can also use an OAuth token to authenticate to EWS - but only if the delegate Full Access To Mailbox is selected. This also doesn't require admin consent but is a big scope (but necessary because EWS doesn't understand scopes)
I'm just getting started porting my old code over to the new google apps json service but I'm not clear on the oauth.
I'm looking at:
https://developers.google.com/admin-sdk/directory/v1/guides/prerequisites
It says:
"Set up a new project in the Google APIs Console and activate Admin SDK service for this project. See the Google APIs Console Help in the upper right corner of the Console page for more information about creating your API project. "
My product gets installed at each client location. Do I create the app using my key then distribute this to my customers or do I use their key in my app that runs at their site? Do I also need to enable the admin SDK in addition to enabling API access?
Do I create the app using my key then distribute this to my customers or do I use their key in my app that runs at their site?
Do they have access to the source code? If true then it will be known to them.
Whether it is your key (an API project owner by you) or theirs depends on the kind of software you offer (tailored or common service (webapp?)) and who will be responsible of the quotas, billing (if needed) and maintenance.
Do I also need to enable the admin SDK in addition to enabling API access?
Yes.
FYI:
API projects can hold up to 20 accounts
Users can own several projects (don't know how many)
Projects can be shared with other users or Groups
In my external application i need to find all sites with write permission for logged in user.
I am using WSS.
Is there any web service available for this task?
Or can i send a Query and get the desired results?
You need to use the client object model (see this msdn article http://msdn.microsoft.com/en-us/library/ee535231.aspx) to work with SharePoint for outside the system.
use SharePoint webservices. They have a special asmx for permissions:
/_vti_bin/permissions.asmx
This Web service is used to obtain the permissions assigned to a list or site, add new permissions, and update or removing existing permissions.
Here's a blog post about using the permissions webservice:
example