We have an Office 365 tenant that we are using for our basic AD functions (joining desktop PC's, authentication, etc..) for our organization.
We're also building a stand-alone mobile and web application. We have an Azure subscription we've tied to our primary AAD tenant. And we're likely to have a separate dev/test subscription.
We're wanting to join our applications resources to an AAD for management purposes, but my question is should we join these to our regular AAD? I don't think that's wise. So what are the alternatives? Create another AAD? We plan to use Azure B2C for the web and mobile authentication.
Do we create another tenant? Partition our primary tenant off in some way (like traditional AD forests and trees)?
I'm trying to keep the application isolated for security purposes from our organizations usage.
FYI, we do not have any on-prem legacy AD.
This depends on what the purpose of your applications are. if you are selling your application and creating a multitenant application, etc. There may be a case for separate tenants (B2C).
But in general, try to avoid creating too many tenants, it can become a management nightmare.
Now to answer some of your specific questions. When you create azure b2c, it is actually a new AAD Tenant, with a different domain name.
In terms of the dev/test subscription, it should be a subscription tied to the same AAD tenant. You would not create a separate tenant for that. unless you absolutely need to test things with a totally separate Directory (eg, editing random Global Azure AD settings that you don't want to do in your primary tenant) but again, that means it becomes a management nightmare as 1: you don't want to create multiple users in different tenants for the same person. This means you'll need to use azure b2b, to federate users and setup separate permissions, etcetc.
In azure Ad you cannot create child domains, that concept is different from on-prem AD. its just not how it works.
Here's a good read on some of the rarer scenarios to create more tenants:
https://itconnect.uw.edu/wares/msinf/aad/new-aad-tenant/
If you plan to use B2C then the app registration should be done there. You can later federate with your primary AD tenant.
Related
Consider the following case, for my application:
I have a website
The website sits on top of an azure api and gets data from cosmos DB
The data from cosmos DB is specific for different organizations
Different organizations should be able to have an "admin" appointed by me
The organization "admin" should be able to add his colleagues under the same organization
The users within a particular organization should only be able to view the data specific to their organization
Considering the above use-case, I have thought about using Azure B2C because:
Everything is already inside azure
I don't want to do security myself
However, I am unsure, if it is actually possible to achieve this with azure B2C? I can't seem to find any similar use-cases in the AD documentation. Hence why I start to think, that I'm going in a wrong direction...?
Therefore, can Azure AD B2C offer, what I want to achieve? (do I need a tenant for each Organization)
In case, Azure AD does not offer support for my use-case, what would you then recommend me to do?
As a white-label service, Azure AD B2C cannot be used as a built-in security provider for other Azure services without writing custom code to translate whatever authorization model you maintain in Azure AD B2C into access patterns for CosmosDB or other Azure services.
CosmosDB does have it's own in-built notion of users and permissions which you might map in some way (using custom code) to Azure AD B2C users. https://learn.microsoft.com/en-us/azure/cosmos-db/secure-access-to-data#users
You could also use CosmosDB's integration with Azure AD (not B2C) for RBAC controls: https://learn.microsoft.com/en-us/azure/cosmos-db/role-based-access-control
Finally, Azure AD B2C does not provide any out-of-the-box administrative tooling for the kind of delegated user administration model you described. Again this would need to be a custom coded admin UI or you'd need to use a third-party solution such as Saviynt for delegated administration: https://learn.microsoft.com/en-us/azure/active-directory-b2c/partner-saviynt
I am a little bit confused about Azure tenants, AD and subscriptions.
Imagine a customer starting from scratch.
Can I say that the first step is creating (subscribing) a tenant?
After creating a tenant, is there a default AD? Can they create other ADs inside the same tenamt?
Can they create more subscriprions for a single tenant?
Given they can, can a subscription be associated to one or more ADs?
Is there any page or document describing the concepts and the design of Azure components (tenants, AD and subscriptions)?
Regards
marius
When you signed up to Azure using a Microsoft account, then you will get Azure with a Default Directory. A tenant is associated with a single identity (person, company, or organization) and can own one or several subscriptions. Single tenant can have multiple Active directories, but a single directory can only have 1 tenant.
There is similar SO question which can help you in understanding more.
Is there a recommended Azure AD strategy for managing internal and our partner users?
We know we can add external users to our Azure AD but we would like a clear separation between the internal and partners users.
I see in Azure you can add another Azure AD so wondering if we can add a new just for external users. But I'm not sure what effect this would have to our current company Azure AD and whether it would have access and/or impact on the features we have in our Azure AD (e.g. O365/Sharepoint/etc).
Or is it recommended just to use groups in Azure AD to separate the internal and external users?
is it recommended just to use groups in Azure AD to separate the
internal and external users?
I think this is the best way to manage your users and partner users.
If you add partner users to another Azure AD, they will not access your default Azure AD resources and app.
Different Azure AD have different resource groups and APP.
will setting "Application is Multitenat" make my application work with other tenants which are not registered in my azure subscription. which are not part of my active directory. will setting this option work with any #######.onmicrosoft.com. the image you see is from azure active directory web app page. i have register my web application to consume the office 365 api as describe in page https://github.com/OfficeDev/O365-WebApp-MultiTenant
In context of Azure AD:
A single tenant application is only available to users of Azure Active Directory (Azure AD) where this is created.
A multi tenant application is not only available to users of Azure AD where it is created but it also available in other Azure ADs. Users in other Azure ADs have to explicitly grant consent to the application in their Azure AD. When an application is added to another Azure AD, that application essentially becomes a user in that Azure AD as a Service Principal.
A single tenant application means application is hosted specific for a single client. Reasons may be specific business needs OR regulatory compliance OR they can be n numbers of real scenarios you can imagine.
In multi tenant application is available to group of clients. Reasons here can be common business needs, no regulatory compulsion, less cost in supporting maintenance & usage as same application is used for multiple clients.
Practical Example is below (Directly taken as it is from MSDN):
One of the first architectural decisions that the team at Tailspin had to make about how the Surveys application could best support multiple subscribers was whether it should be a single-tenant or multi-tenant application. Figure 1 shows the difference between these approaches at a high-level. The single-tenant model has a separate physical instance of the application for each subscriber, while the multi-tenant model has a single physical instance of the application shared by many subscribers.
It’s important to note that the multi-tenant model still offers separate views of the application’s data to its users. In the Surveys application, Client B must not be able to see or modify Client A’s surveys or data. Tailspin, as the owner of the application, will have full access to all the data stored in the application.
For more details : refer Hosting a Multi-Tenant Application on Windows Azure
Our company is considering using AAD B2C as the backing store for our SaaS user accounts. Our plan is use Resource Manager templates to deploy the Azure infrastructure (web, storage, sql, etc) for each client. AAD B2C will be part of that if this works out, but as of now there doesn't appear to be a way to include AAD B2C in resource manager templates.
My view of the intent of the B2C product is that it serves as a replacement for the auth and user store components of an app, and should therefore be considered infrastructure. Right now the hierarchy between AAD and resource groups in the new azure portal doesn't reflect that - resource groups (and their resources) appear 'under' an identity in an AAD account. But why is that? Is an AAD a parent to a resource group? I'm trying to understand how the two fit together.
If AAD B2C is really intended to serve this purpose when it leaves preview, it will need to support automation. After a quick search I can't even find code samples to provision a new directory, let alone do so using Resource Manager templates.
Am I looking at this all wrong?
Currently there is no way to automate the creation of an AAD B2C tenant like there is also no way to automate the creation of an AAD tenant.
After you created a tenant you can access it programmatically via the Graph API. You can read more about this in the documentation: https://azure.microsoft.com/en-us/documentation/articles/active-directory-b2c-devquickstarts-graph-dotnet/.
The first paragraph of this documentation mentions the following:
Azure Active Directory (Azure AD) B2C tenants tend to be very large. This means that many common tenant management tasks need to be performed programmatically. A primary example is user management. You might need to migrate an existing user store to a B2C tenant. You may want to host user registration on your own page and create user accounts in Azure AD behind the scenes. These types of tasks require the ability to create, read, update, and delete user accounts. You can do these tasks by using the Azure AD Graph API.
Caution: at the point of writing this is still in preview so the API can change any time and you have no SLA.
For the latest status about which Azure services support ARM you can read this page: https://azure.microsoft.com/en-us/documentation/articles/resource-manager-supported-services/