For security reasons, we decided to create separate accounts for our Azure deployments.
Therefore, some users have an email account that holds Visual Studio license, and a separate account that has privileges on Azure subscriptions and no email address.
We use ADFS federation to log in to Azure. I tried to add the two accounts separately, but each time I validate authentication, it only displays my main (email) account.
I know that to log in to the Azure portal with my other account, I have to use Firefox.
Is there any way to do that with Visual Studio?
Thanks
Related
Currently, I developing Microsoft ChatBot that needs login via Microsoft Graph.
After I log in the error display as below.
When you registered your app, you chose one of three supported account types:
Accounts in this organizational directory only (i.e. one Azure AD tenant only)
Accounts in any organizational directory (i.e. any Azure AD tenant)
Accounts in any organizational directory and personal Microsoft accounts (i.e. any Azure AD tenant and any personal Microsoft account)
If you chose the first option, your app is not considered "multi-tenant", and you cannot use the "common" endpoint, as the error message indicates. You have two options here:
If your application is to be used by users from multiple organizations, change the intended audience to "Accounts in any organizational directory" (Azure portal > Azure Active Directory > App registrations > Authentication).
If your application is only intended to be used by one organization, then update your code to use the tenant-specific endpoint (i.e. https://login.microsoftonline.com/{tenant-id}/..., instead of https://login.microsoftonline.com/common/...).
We have almost 16 users in our Azure DevOps Organisation. I am having the admin privilege for the azure account. I saw a few blogs regarding Active Directory Enabling method and all. But it was not clear.
How can we manage this restriction in Azure DevOps.
NB:-Our users are accessing Azure DevOps through their outlook account.For ex:-sample.orgnization#outlook.com
Depending on your setup, there are a couple of options:
Azure DevOps configured as MSA backed with AAD guests in Azure DevOps
When your Azure DevOps account is configured to be backed by Microsoft Accounts (formerly Live IDs, or Outlook.com or Hotmail.com), it can add Azure Active Directory users as guests into the account. This feature was added last autumn.
In this configuration, you can invite AAd and MSA users directly from Azure DevOps and the MSA users don't get any access to the Azure account.
Azure DevOps configured as AAD backed with MSA guests in Azure Active Directory
When your Azure DevOps account is configured to be backed by Azure Active Directory, it can only add users who are known in Azure Active Directory. However, you can invite Microsoft Accounts into your AAD as guests. You can even invite users from other AADs as federated guests.
In this configuration you can only invite users who are known by AAD into you Azure DevOps account. If they're not in AAD, you'll have to invite them into AAD first.
Switching
You can switch the account between the different association modes. To migrate existing users from one type to another (AAD->MSA, MSA->AAD) you currently need to open a support request to get all of the users mapped over. In this scenario you get an excel export from your account and you provide a mapping between the old and the new uesr account. Support will mapthem for you.
Manual process
You can also take a manual approach. This model isn't well documented. And when manually mappign you'll have to re-apply the security permissions manually as well. As such, thsi approach isn't recommended.
Once in AAD
Once your users are all in Azure Active directory, you can set policies on their access patterns, restrict IP addresses, require 2FA tokens and such. The value is questionable for external users as it won't work for all guest types. It will be valuable for your own users. You can enforce policy on users in your AAD. It's recommended to work with your federation partners to ensure that they're also using the right policies for their own users.
I think this will help you, I also faced the same problem which I mentioned, this article explained in details very clearly that how we can apply 'Conditional Access Policies' to avoid unauthorized access on Azure repositories(Code). after apply the policies on Azure portal, We need to enable the option on dev.portal Enable Conditional Access for Azure DevOps, Hope this will helps you.
I have created a web app in ASP.NET. I want to deploy this on Microsoft Azure. I have been given an account from my IT company. We need subscription to deploy on Azure, for sure. Then, I have been added as co-admin to subscription by my company, but still I am not able to integrate my account with Visual Studio. Do I need to do any setting? Or, this permission is also not enough ?
Co-admin on subscription is definitely enough. You are allowed to do anything in the subscription. Have you tried logging in to https://portal.azure.com with the account?
EDIT: Try opening a new Incognito/InPrivate window with no logins active, and try again with the credentials, making sure they are the ones that are co-admin.
I am trying to create a SPA that uses Dynamics CRM Web API. While registering my Application in Azure Active Directory I can not find Dynamics CRM Online in the permissions to other applications window.
Do I need to upgrade my subscription or am I doing something wrong?
It's easiest if your azure account uses the same login that has access to CRM. Then you will see CRM as an application option.
If the Azure account you're using isn't the same one that you use to login to CRM, you'll need to connect the two. In order to do this, though, the O365 account you use for CRM needs to be a global admin in O365. This page has instructions.
To associate an existing Azure subscription with your Office 365
account
Log on to the Microsoft Azure Management portal with your existing
Azure credentials (for example, your Microsoft ID such as
user#live.com).
Select the Active Directory node, then select the
Directory tab and, at the bottom of the screen, select New.
On the New
menu, select Active Directory > Directory > Custom Create.
In Add directory, in the Directory drop-down box, select Use existing
directory. Check I am ready to be signed out, and then select the
check mark in the lower-right corner. This brings you back to the
Azure Management Portal.
Log in with your Office 365 account
information. You will be prompted whether to use your directory with
Azure.
Important To associate your Office 365 account with Azure AD,
you'll need an Office 365 business account with global administrator
privileges.
Select continue, and then Sign out now.
Close the browser and reopen the portal. Otherwise, you will get an access denied error.
Log on again with your existing Azure credentials (for example, your
Microsoft ID such as user#live.com). Navigate to the Active Directory
node and, under Directory, you should now see your Office 365 account
listed.
If your CRM O365 doesn't have global admin privileges, I would recommend just creating an azure account with the same account you use to connect to CRM According to the SDK, "the account is free for application registration and your credit card won’t be charged if you only follow the procedures called out in this topic to register one or more apps."
I followed the steps as per
https://github.com/OfficeDev/O365-WebApp-MultiTenant and added the connected service. However this does not register the app under Windows Azure Active Directory Applications. I have properly linked my office 365 account into Azure. However when I add the connected service it is still empty. Is this a known issue and what is the work around?
No, this isn't a known issue. The "Add Connected Service" wizard is not generating a client ID and secret in your web.config?
As a workaround you could login to the Azure Management Portal and register the app manually, then put the client ID and secret into your web.config.
I just had the same issue and spend some hours on it. Finally it turns out that I had used a user account to log in in visual studio that was assigned to a different MS Azure account.
In my case I was using the user of production environment instead of my own developer account to log in.