I'm a QA team member and responsible for granting access to developers, there is more than 100 developer and sometimes I forget revoke the access which was granted, it has dire consequences for me! I developed an application to remind me to revoke accesses, but still I'm facing the same problem because there is two other colleagues granting accesses
is there any option in TFS to grant accesses for a limited time?
thank you in advance
You should manage access to TFS via an Active Directory groups. It's easy to manage AD group membership via C# or even via PowerShell, and then all you need to do to revoke access is pull the user out of the AD groups.
Related
I want to manage group membership for a single group in an automated way. My AD administrator has created an app & service principal, but is hesitant to give it GroupMember.ReadWrite.All permission. This permission seems to give ability to manage membership for all groups.
Is there a way to limit permissions or scope to manage membership to a single AD security group?
I think currently this is not possible because, Most of the Graph permissions are tenant-wide, without a way to restrict them in scope.
such as the app access policies we have in Exchange Online: Application access policies
Hope this is Helpful.
I'm developing an application on Microsoft Graph that runs as a daemon, and needs access to many accounts. As a result, I'm using a service account, also known as client credentials (using this method).
I can request the proper scope (calendars.readwrite) however as far as I can see, I cannot restrict to which calendars I have access. In my case, I only need access to the meetingroom calendars, and I'm afraid that organisations will not allow my application if I can also read and write from/to the CEO's calendar.
Is there any way (either while creating the app, or during/after giving admin consent) to restrict my app to only a subset of calendars? Or should I approach this problem differently and (e.g.) not use a service account in the first place?
In my application I want to be able to programmatically create and delete user accounts in Azure Active Directory. This program needs to run unattended.
I am able to create Azure AD users but keep getting failures when deleting a user account. Specifically, I am getting the following error message:
Microsoft.Graph.ServiceException:
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation.
I think this is by design because the documentation states that only delegated permissions are supported. Can someone from MS Graph team confirm that it is not possible to delete AD users in unattended fashion (e.g. without prompting for admin user account and password)? Is this functionality going to be supported in the future?
Are there different ways to solve this problem? Would the Azure AD Graph API work for this (even though it is not recommended to use now)?
That is correct, DELETE /users/{id} requires Directory.AccessAsUser.All which is only available for delegated scenarios.
This is unlikely to change given the security exposure this would introduce. A rogue application creating users would certainly be extremely annoying, but a rogue application deleting users would be outright catastrophic.
My suggestion would be to have your application maintain a "deletion queue". Whenever you need to delete a user, simply add that id to the queue. Then provide an interactive experience for Admins that allows them to login and delete the queued users after reviewing the list.
We are developing a web application using Microsoft Graph, where the signed in user can, Export all the calendar events to a third party calendar Application. After this initial export, we need to keep the exported data in sync with calendar changes via service app (a scheduled task running on server). This need to be a multi tenant application, as people from different organizations should be able to use this service.
Right now we did the authentication using OAuth 2.0 and OpenID Connect as described in this sample. Later we understood that the access token we get using this method cannot be used in the service app without user interaction. Considering our scenario what is the best way to achieve this?
I have read about App-only authorization method to do this. If we use this authentication method, the app need to be consented by a tenant administrator and the these applications are quite powerful in terms of what data they can access in the Office 365 organization. Considering we are developing a product used by different organizations, will it be feasible to use this method?
To use the client credentials OAuth2.0 flow (aka "App-only" or service account access depending on who's documentation you're reading) the admin for each tenancy will need to specify which scopes your daemon process can have for users in their tenancy. The end users can't give these scoping rights to your code themselves (as far as I know at least).
One thing to watch out for is that currently Graph API doesn't allow you to mess about with calendars that are attached to Office 365 Groups if you're using the client credentials flow. This is a pain for us, so we've raised it as an issue that needs fixing in the Office 365 feedback system. if that's an issue for you or anyone else, please throw a few votes at it so that it gets more attention at Microsoft. :-)
We have recently installed TFS 2010. Our Active Directory users (i.e. my company's staff) can access it just fine.
However, we also have contractors working in the office who do not have an AD account. I am having difficulty trying to get the non-AD users to connect to TFS through Visual Studio. The contractors are on the same LAN but have no AD account, which we do to restrict access to other resources on the network.
I created local Windows user accounts on the server for the contractors. With the local account they can access the TFS web front end but still cannot connect through Visual Studio.
Is there any way to do this? Do the contractors need to have Remote Desktop access to the server itself?
You should definitely give your contractors AD accounts. If you want to restrict access to internal resources, you can use Organisational Units in AD, like
MyCompany
Employees
Contractors
And set access restrictions to your resources according to groups linked to the OUs.
Giving remote access to the server will just create another set of issues.
When you install a non Express version of TFS, you need an AD for authentication, you can't use properly the TFS server from a non AD account.
From this point you have two solutions:
Create AD account for contractors (one per company or one per user, your call).
Create a domain Trust between your domain and the contractor's one. See this documentation for more info.
I don't understand clearly the Remote Desktop part, explain please.