I need to build a solution that utilizes Azure B2B Collaboration to on-board customers from different organizations to use my system.
Each customer may have 100's or 1000's of users, where some may have Azure AD and other don't.
The application will have different user roles/groups structure that controls access to my API's.
What is the best way to design this and can you provide references?
Option 1: Create a separate Azure AD for each customer
Each customer will have their own Azure AD and I can use Azure Groups to control access.
What is the limit of Azure AD's per subscription? (can't find a
definitive answer in MS docs) https://learn.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-service-limits-restrictions
Is this a good "Azure" practice? can you provide references?
Any info about structuring/organizing this for easy maintinance.
Any complications that I need to be aware of?
Option 2: Create a single Azure AD for all customers/users
All users for all customers will be added to a single Azure AD and for users segregation, each customer's users belong to a separate Azure Security Group.
In this scenario, I will probably need to maintain each customer groups in a local database since they may have different groups.
Any concerns from having all customer's users in the same directory?
Options 3:???
In my opinion single tenant is better. Creating a tenant for each customer makes management much harder (also login becomes harder to implement). Limit of Azure AD per subscription probably does not exist since directories are above subscriptions in the hierarchy. Yes, you can setup a group for each customer and keep the id of the group in your database.
The users will be added as Guests to your directory, make sure that the setting Guest user permissions are limited is enabled in the external collaboration settings.
That will make it so that they cannot access the user or group list at all in your tenant.
Related
Do I have the client setup an account using their payment, contact info etc? or do I use my own account then somehow transfer everything to the client? Also, How do I give access to devs?
Thanks.
There are different strategies you can employ to decide how you want to design and organize your Subscriptions. The Subscription decision guide within the Microsoft Cloud Adoption Framework for Azure can help you establish that structure.
As for granting access to others, Azure role-based access control (Azure RBAC) is a system that provides fine-grained access management of Azure resources. Using Azure RBAC, you can segregate duties within your team and grant only the amount of access to users that they need to perform their jobs. Instead of giving everybody unrestricted permissions in your Azure subscription or resources, you can allow only certain actions at a particular scope. You can further refer to the best practices for Azure RBAC doc to know more.
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.
We have an Azure AD which is managed by a third party. Our domainname is validated against it. We are now bringing this in-house and want to know the easiest way to move it? It doesn't have many objects, so happy to recreate them but to do so, I need to validate our domain against this Azure AD instance. If I do this, I am concerned it will break the existing which would be a problem as we have users using it. Can you have a single domain validated against two directories (no on-prem integration). Also, is there an easier option? I don't mind users having to reset their password.
No, you cannot have one domain name verified in two Azure AD tenants.
The title of this question indicates a common misunderstanding is at play here: Azure AD tenants are not resources within an Azure subscription. If anything, it's the other way around: an Azure subscription is associated to an Azure AD tenant. Read more on the relationship between an Azure subscription and an Azure AD tenant at "How Azure subscriptions are associated with Azure Active Directory", and on how to transfer Azure subscriptions across Azure AD tenants at "Transferring ownership of an Azure subscription."
If there already exists an Azure AD tenant with your domain name, you should simply take control of the tenant. If you already have access to a user account that is a tenant administrator, then you simply need to evict (demote, disable or delete, depending on your situation) the users from the third party. If you don't, you can ask the third party to make your user an admin. (And if that is not possible either, you can contact support to prove ownership of the domain name.)
I have a business requirement where Azure Subscription owner will Provision User Groups like Infrastructure Admin, Billing Admin, Enterprise Users. Ifra Admin people should login to this Portal & can only see options related to Infra provisioning. Billing Admin people should have access to Azure usage Enterprise wide - And they should be able to generate bills for respective teams(which are part of the organization). Enterprise Users are those who want to procure azure storage, VMs etc. and they want estimate cost for required infra.
I am looking out for a solution/approach for this requirement. If Azure Portal is already providing this feature then please provide me reference material. If i should build new custom Web application which internally use Azure APIs then let me know about that option as well.
If there are any products which already doing this even am open for that.
Deeply appreciating your help. Thanks a lot :)
Vishal.
Let me answer by breaking your question in 2 parts:
Managing Users - This is something you can do today in Azure. Some time ago, Azure announced Role-based access control (RBAC) and that fits the bill nicely for you as far as managing users and granting them permissions to do things. So in your scenario, the owner will create users and groups in Azure Active Directory and then put these users and groups in appropriate roles. When a user or a group member tries to manage the resources (either by logging into the portal or using other tools like Azure PowerShell Cmdlets), they will only be able to do things the role they are in allows.
Managing Billing - Though Azure Portal exposes the billing functionality (and there's a billing/usage REST API), it does not have the capability you're looking for. What you would need to do is look for ITFM (IT Financial Management) Systems that has support for Azure. Off the top of my head, two tools come to my mind - Cloudyn & Cloud Cruiser. You can learn more about it here: https://azure.microsoft.com/en-in/documentation/articles/billing-usage-rate-card-overview/. You could always consume the Billing/Usage REST API to create a solution of your own. If you're writing your own solution, you may want to check out Billing Samples on GitHub.
SharePoint does integrate active directory accounts, of course, but how about security groups? Have a few sites where I'm fairly confident access is going through an existing Active Directory (AD) security groups (i.e. only an AD security group has been granted permissions through the 'People and Groups') In another situation, where I created the AD group and granted it permissions to a site, the customers were not able to access immediately. Eventually had to fast-track it and add the individuals to the People and Groups to keep the project going, but hoping not to have to maintain it that way.
Any specific requirements of the security group in AD? Universal, Global, or domain local? Is there any time delay between modifying group members in AD and having that take effect in SharePoint?
Any AD group type is usable by SharePoint so long as that group is usable by the server SharePoint is running on. Said another way, if you were using the OS level tools on the server and the OS recognizes your group, then you can use it in SharePoint.
As for when group memberships changes become effective, it has always been near real time for me but I can't say that I can speak to all possible AD topology deployments.