Can I add other developers to my Nest account? I would like each member of my team to have their own Nest user account but share the same client and test devices.
Unfortunately not at this time.
The best practice with the current setup would be to create a group Nest Account for development (using a group email address, most IT departments have self-service for this) and a separate account for production (which you should do anyways)
If you would like to suggest better account management features, the best place to do so is on the Product Suggestions board in the Nest Community.
Related
Context:
We are using Azure DevOps and we are starting to leverage more and more PATs in our DevOps cycles and processes. We have about 30 users and each one of them creates a bunch of them under their personal account for different use cases.
Here are some scenarios where they are used:
Self-hosted agents configuration (Windows and dockers)
API call for Microsoft Teams bots
Homemade integration with Azure DevOps and other systems
etc.
Basically, we are starting to loose a bit the control over:
What kind of PATs are created
Where are the PATs used
Which scopes defined on the PATs
As an example, we have some users that create PATs to configure agents. They will give the full access to this PAT, instead of selecting the proper scopes for it. As we know, end users don't really care about security and we are aware that we need educate our developer. However, we still want to have way to control those PATs.
Questions:
Is there a way to view in the organization level all the PATs that used?
Is it possible to remove the possibility for a specific user to create PATs and only give that feature to the admin users?
Is it possible to revoke all the PATs on the organization level?
Can you share your experience(s) and tips on how you efficiently handle PATs in your organization and more specifically on the security aspect?
Maybe this could help you to restrict the usage of the PATs
https://devblogs.microsoft.com/devops/new-policies-to-restrict-personal-access-token-scope-and-lifespan/
Is there a way to view in the organization level all the PATs that used?
Not that I know
Is it possible to remove the possibility for a specific user to create PATs and only give that feature to the admin users?
From the article, yes it is now possible for the administrator to do so
Is it possible to revoke all the PATs on the organization level?
Yes it is, see https://learn.microsoft.com/en-us/rest/api/azure/devops/tokenadministration/token%20revocations/revoke%20authorizations?view=azure-devops-rest-5.0&preserve-view=true
I'm completely new to ms world and trying to access API under my personal account
https://learn.microsoft.com/en-us/graph/api/group-list?view=graph-rest-beta&tabs=http
However this API says that it can only be accessed using Delegated (work or school account).
Can anyone explain how to setup new organization account (taking into account that we have no organization yet), which ms service to use and which plan to subscribe for, if needed. They have so many services and it looks so confusing to assemble all this together, so please help.
As I said in the comments, first you need to have a tenant. If you have not buy an Azure subscription yet, you can also use a free account.
Then you can create a new work account or invite guest users in the tenant.
We are building a enterprise product, and expect a lot of customers, to not have active directory of their own.
We plan to use AAD as our IAM provider.
We plan to create a master AAD for the product, and then invite users of each customer (tenant) as external users to the master AAD, using their business email id. Each set of users for a given customer, will be added to an external group for manageability.
Would this be the right approach, for supporting multi-tenanted IAM for a product hosted in Azure?
It's a pretty hard question. AAD's multi-tenancy basically requires the org to have an AAD to have proper separation etc.
But in the case of an org not having an AAD, this is one option.
One crucial thing you must not forget with this path is to turn on the option in the AAD tenant to restrict Guest user permissions. This makes it so that the invited users can't just go to portal.azure.com and get a full list of all users in the tenant. At least usually this is a desired thing when multiple clients are in the same tenant.
Other options could be:
Setting up an AAD tenant for each customer
Good separation for customers
There might be a limit how many you can create
I'm not aware of an API you could use for this (but hey Selenium works :D)
Set up your own identity provider with e.g. IdentityServer
Maximum customizability
Lot of work for you to develop and maintain
Everything would of course be easier if they just had an AAD :)
It would depend on some details of the approach you want to follow. If you are expecting for them to use their business email, then you may consider having Single Sign-On (many organizations expect not needing to duplicate accounts and you may want to delegate your customers the hassle of resetting passwords).
Also, you need to determine what kind of isolation need(do you want to have a single set of users or have a clear separation by tenant?) and the budget (AAD cost is measured on a per-user basis) you have for this? Azure AD B2C could be also an option, or as #juunas mentioned, implementing your own solution with something like IdentityServer.
I am a part of a group trying to create an Amazon Mechanical Turk Requester task. We'd like to either have a group account or have multiple accounts with access to the same project. I've been looking around and cannot find a way to do this. Is it possible to make this happen without sharing a single account?
This may not be perfect, but if you're an MTurk API customer, you can use Identity and Access Management (IAM) to have a single account (with a credit card on file) but provide multiple sets of API credentials (AWS Access Keys and Secret Keys) that you can provide to reach person/group that wants to use the account. This isn't a perfect solution because:
It is only applicable to the MTurk Application Programming Interface (API)
There aren't quotas or controls to limit spending on one person vs. another
Each account can still access each other's HITs (it isn't separate accounts)
You can learn more about IAM support in MTurk here: https://blog.mturk.com/introducing-mechanical-turk-api-support-for-iam-credentials-8f2de8cd6afb
There is not currently a way to do something similar in the Requester Website (requester.mturk.com).
Hope that helps a little.
From web search it appears that to be able to manage Windows Azure services, you need an account with one of the admin roles (service administrator, co-administrator etc).
From project management point-of-view, what is a good strategy to manage accounts for your company if you have several developers working on Azure?
Examples
A simple strategy could be to have a few designated administrators (e.g. team leaders) who upload the code while other developers use Azure Emulator on their machines.
Another example would be to have a shared Azure account used by many developers (not sure about licence implications for this one!).
These are just off the top of my head and have their drawbacks. What strategies do you use?
2 Places I've worked we've done the following.
Single Common A/C
Create a common email-distribution group (myteamonazure#mycompany.com)
Register this mail address as an MSN Passport
Use it to sign up with Azure.
Pro's: Everyone on the team gets mails regarding the account.
Con's: If someone leaves the team, we need to change the account password.
Individual accounts
Let each person signup with their own account. (Mandate it must be their company email... not personal msdn passport)
Make one person the super-admin, and the rest co-admins
Pro's: If someone leaves, it's far easier to just revoke their credentials/privs
Con's: Lots more accounts to keep track of depending on the size of your team, particularly if you're company has a single Azure Account, with lots of different apps/projects hosted on it.
Personally, I prefer the second option as it's more secure/easier to revoke access to individuals.