I can't find an official answer for this. My researches on google say things like...
It's not necessary because Azure AD B2C is geo replicated, resilinece, bla bla bla bla bla...And even in an event of the 3rd world war, Azure AD BC2 will be up and running.
All right, nice speech, Microsoft. Very good for your sales team, but...
We have clients. Clients are paranoids. They want us to show how we are doing the backup.
Also, what about a clumsy admin that's accidentally deletes everyone ?
And Azure AD B2C stores much more than user data. You can store custom user properties, App Registrations, Flows and many other things that's composes the archtecture of your solution. This must be protected as well.
So, since there is no out-of-the-box solution for this...Anyone knows something non official ? Maybe a power script or a non documented solution ? The solution at Back and restore for Azure AD B2C is no longer valid.
what about a clumsy admin that's accidentally deletes everyone ?
You can demonstrate how you have restricted Admin access into a
Production AAD B2C directory. You can demonstrate that you fully
orchestrate your directory configuration through CI/CD pipelines with
gated deployments through multiple AAD B2C tenants that act as lower
environments.
You have 30 days to restore all deleted objects.
Nobody can delete all accounts via the Portal, and nor should there
be any CI/CD pipeline built to perform such an action.
And Azure AD B2C stores much more than user data.
User object - Dump users via Graph API. ObjectId can not be restored in the case of permanently deletion by an Admin.
Application Registrations - Config should be in a repo and controlled with CI/CD. If permanently deleted, you should demonstrate how to rebuild an App Registration using the config from your Repo, and update the Application code to reflect the new ClientId/ClientSecret. ClientId cannot be restored from a permanently deleted Application Registration.
User Flows - Config should be in a repo and controlled with CI/CD
IdP Configurations - Config should be in a repo and controlled with CI/CD
Custom policies - Config should be in a repo and controlled with CI/CD
Generally all features that you've configured have MS Graph API configurable endpoints that you can manage via CI/CD, and maintaining these configs in a repo.
According to MS information here they recommend using Azure Backup for Azure AD B2C. I have not tried it yet but hope to soon.
Related
We've been told by Microsoft support that Azure DevOps Services supports tenant restrictions. While we have tenant restrictions enabled on a number of other services, it does't seem to apply to DevOps. Not only can we still log in to organizations outside of our tenant, we can also log in to our own organization and, if our corp email is added as a user in that org, the organization also shows up. I'd expect that our users would be blocked from logging into or accessing any external orgs.
I'm a little confused about why this isn't just working as expected and despite them saying Azure DevOps Services supports tenant restrictions, I'm not finding much documentation to back that up.
Have you been able to migrate to Azure DevOps Services and ensure that your users are only able to access orgs within your own tenant? How?
Azure DevOps Service supports the Azure Active Directory (Azure AD) tenant policy to restrict users from creating an organization in Azure DevOps. This policy is turned off, by default. You must be an Azure DevOps Administrator in Azure AD to manage this policy.
Check following link for more details:
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/azure-ad-tenant-policy-restrict-org-creation?view=azure-devops
Notice:
This policy is supported only for company owned (Azure Active
Directory) organizations. Users creating organization using their
personal account (MSA or GitHub) have no restrictions.
https://devblogs.microsoft.com/devops/policy-support-to-restrict-creating-new-azure-devops-organizations/
We finally received a more concrete answer to this question from Premier Support. Sounds like this wasn't entirely clear internally either. Azure DevOps Services supports TRv1 which provides tenant restrictions from client to proxy, but does not support TRv2 tenant restrictions which provides server to server restrictions. TRv1 will prevent you from authenticating against an org outside your tenant directly but does nothing to prevent the background authentication that happens if your account is configured to be able to access a secondary tenant's org. The server to server connection strips off the header information necessary to restrict you from accessing the secondary tenant. While this feature may be on their radar there is no expectation or firm timeline for it's release at this time.
We will be building a couple of non-interactive scripts and console applications which will be invoking the Azure DevOps REST API to do various tasks. These apps and scripts will be executed via a job scheduler. What authentication scheme would be the correct one to use for this scenario? It seems like a PAT would work, however, I really don't want the jobs to be tied to a specific user identity and Azure DevOps does not support service principles. Is the correct approach to establish a "fake" Azure Active Directory user and use that user as the owner of the PATs? Is there something else that I am missing here?
Looking at the Authentication Guide, it seems like all of the mechanisms referenced result in some form of interactivity.
Also, we have Conditional Access Policies being enforced in our Azure DevOps organization. One of those policies is the requirement for MFA. If we use a PAT, how will that work? According to this link, it sounds like access may be blocked.
Personal access tokens (PATs) are used for personal authentication. They are alternate passwords that you can use to authenticate into Azure DevOps.
Really don't want the jobs to be tied to a specific user identity and Azure DevOps does not support service principles.
Yes, as you have pointed out. It doesn’t support to create a PAT token with a service account in Azure DevOps Service.
That would be ok to use the public fake MFA account to login Azure DevOps Service. And then use that account to generate PAT token. When request API, others simply use that generated PAT token to authenticate.
With CAP enabled the doc is clear. For Web flows, CAP is honored 100%. That means in most of the situations, Rest API will not be affected.
The limitation is third-party client flow. Some actually due to configuration of third-party. There's nothing we can do in Azure DevOps. You have to follow the policy mentioned in that link. If users do not meet IP range, it will be blocked.
We have a situation where we are in development and experiencing a lot of delay and resistance from the Azure admin which is creating costly delays and impacting deadlines.
I would like to create our own Azure subscription to allow us to fully admin our environment and pipelines as we see fit, without needing to go through the aforementioned resource. The admin can link our Dev subscription to their corporate AD later.
We already have some projects in VSTS, build scripts, began some CD development.
Obviously on a new subscription we would just recreate the pipelines and resources. However, since it would be a new AD, how would this impact our ability to still view content and resources in VSTS?
Link the new AD to the projects?
You can easily associate a VSTS instance with a different Azure subscription, no need to recreate anything. This can be done via the Azure Portal. It can still be connected to the same Azure AD.
I have a web application deployed on Azure with the Azure Active Directory security enabled (the express setting). So, when I try to access the application, I need to be a part of the AD to have access.
I would like to add more features to the application, like displaying the current user logged in, implement a logout, managing permissions etc... I believe I can achieve all of things with Azure Graph API.
However, to do this, I will need to test some stuff locally. Is there any way to simulate Azure AD locally? It is "switched on" on Azure and everything works great there, but ain't got nothing to simulate this on my local machine.
There is no "local" or "offline" version of Azure AD available.
Your options at this time are:
Test using an actual Azure AD tenant. You can create your own test tenant to allow you to make changes as necessary, postponing the need to work with the admin of your corporate Azure AD until you're ready to go to production.
Create your own Mock STS that implements the OpenID Connect protocol and use that during development/testing. The risk here is that you'll have to make sure that this Mock STS behaves just like Azure AD does or close enough for your purposes.
As a side note, you can create a feedback entry asking for a feature on this in the Azure AD Feedback Forum
I'm working on an application that will allow users to authenticate to Azure Active Directory and then manage resources in their Azure account via Azure Resource Manager API calls.
I've found several walkthroughs on building such an app including this post. However, in the part that discusses authentication with Azure Active Directory, there's a step showing the need to manually retrieve the Azure Active Directory name from the Azure Portal.
The directory name is plugged into app settings (and ultimately authentication calls to the directory) as follows
http://login.microsoftonline.com/{directory_domain_name}/OAuth2/Authorize
Is there any way to programmatically retrieve {directory_domain_name} without requiring users to login and lookup the information in the Azure Portal?
The one answer to this question has a dead link and another pointing to the Graph API, which seems to still require the domain name.
For your particular scenario, look like you want to build an app that will be users from different Azure AD tenants. This scenario is best addressed by building a multi-tenant application.
To make your application multi-tenant, you'll need to go to the Azure Portal and in the Configure tab of your Azure AD application, set the "Application is Mult-Tenant" option to yes.
Once you do this, you can just call
http://login.microsoftonline.com/common/oauth/authorize
http://login.microsoftonline.com/common/oauth/token
And Azure AD will resolve the figure out which tenant to authenticate against based on the the credential that the user types in.
More information on multi-tenant applications:https://azure.microsoft.com/en-us/documentation/articles/guidance-multitenant-identity-authenticate/
Sample multi-tenant application: https://github.com/Azure-Samples/active-directory-dotnet-webapp-multitenant-openidconnect