Reputation: 33
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:[email protected]
Upvotes: 0
Views: 1094
Reputation: 666
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.
Upvotes: 1
Reputation: 114741
Depending on your setup, there are a couple of options:
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.
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.
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.
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 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.
Upvotes: 2