I am setting up the Azure Cloud infrastructure and as a part of this exercise, I want to create and provide the required permissions to the AD Groups, teams will be added into the corresponding AD Groups later.
As of now, my Azure Tenant has five subscriptions (Connectivity, Management, Identity, Production, Dev). I have identified the following list of AD Groups and I am looking for the best practices or recommendations based on your existing implementation.
Considering your 5 listed AD groups meet your org requirement and you'll be adding predefined or custom Azure AD roles to these groups later - You may still need to follow these checks & best practices for your identified Groups. You should note that some of the below considerations/features provisioning will require Azure AD P1/P2 licenses:
Assign at least two cloud-only permanent global administrator accounts for use in an emergency. These accounts aren't to be used daily and should have long and complex passwords - more here.
Give your administrators only the access they need to only the areas they need access to. Not all administrators need to be global administrators - more here.
Periodic password resets encourage your users to increment their existing passwords - more here.
Block legacy authentication protocols like POP, SMTP, IMAP, and MAPI that cannot enforce MFA, making them a preferred entry point for adversaries - more here.
Enforce users to do two-step verification when accessing sensitive applications using Conditional Access policies - more here.
Enable tracking of risky sign-ins and compromised credentials for users in your organization - more here.
Enable automation to trigger events such as MFA, password reset, and blocking of risky sign-ins - more here.
Collaborate with Guest Users by letting them sign-in to Apps and Services with their own work, school, or social identities - more here.
Decide what devices your org allows. Consider Registering vs Joining, Bring Your Own Device vs Company Provided devices - more here.
Identify applications with-in your org (On-prem, SaaS Apps, and other LOB Apps) that can and should be managed with Azure AD.
Remove administrative roles from normal day-to-day user-accounts. Make administrative users eligible to use their role after succeeding a MFA check, providing a business justification or post due approval - more here.
Work with security & leadership teams to create an access review policy to review administrative access based on your org's policies - more here.
Use dynamic groups to automatically assign users to groups based on certain attributes e.g. department, title, region, and other attributes - more here.
Remove manual steps from the AD account lifecycle to prevent unauthorized access. Synchronize identities to Azure AD - more here.
Related
I'm wondering a few things about azure ad.
I currently have a little software with self users managed, in database, with custom properties, and access token self generation, etc.
In order to develop micro services, azure functions, and handle SSO the right way, i would like to migrate my users management to azure active directory, but i'm a bit lost with its features.
Is there a way to handle custom properties for users in azure ad ?
Users can be affected to one or many 'agencies', with some 'roles' in this affectation, such as 'agency supervisor', 'agency user' etc, which aad feature is the best designed for this ? Groups ? Roles ?
Is it a best practice to store custom business-related user properties in an associated database instead of aad ? (Maybe in order to migrate user management later ?)
I'm sorry for these questions but after a lot a research i'm still there.
Maybe some of you have great feedback or documentation for me.
Thank you !
There are two products, Azure Active Directory (AAD) and Azure B2C Active Directory. The first one is used within organizations, the latter can be used for multi-tenant situations where you let people from 'outside' your domain register with their own identity provider (other AAD, Oauth, etc).
Simply said, the AAD is for within the organization, Azure B2C AD is for external users.
The B2C AD features are a layer on top of the 'regular' AAD, so every feature in the AAD is available in B2C AAD as well.
Azure B2C was made with extensibility in mind, and you can (programmatically) add extra schema attributes to the users in your B2C Organization (such as companyId or other identifiers you use to differentiate in your product). We use a mixture of security groups for setting user 'roles', and we use custom claims with the extra schema attributes so I know what client a user belongs to (I'm working on a multi-tenant SaaS app).
If you are going to store a lot of information about the user that is LOB-application data, use a separate database to store that, as the (B2C) AAD is not a very good place to store large amount of (nested) data.
After a lot of research I am still confused about using Azure AD. Here is what I want to achieve.
We maintain users in following order in SQL Server
Organization
Team
User
There can be multiple organizations and a user can be belong to multiple organizations but his/her role will be different like Agent or Team leader or Team manager.
I want to move away from this structure and create the same in Azure AD and authenticate users via Identity provider. How to maintain same sort of structure in Azure AD?
I am looking for an solution with minimal code changes. Any thoughts on this??
You can use Groups in AAD to achieve something similar.
Currently, the following scenarios DO support nested groups:
The concept (you can add groups as members of other groups)
Group membership claims (when an app is configured to receive group membership claims in the token, nested groups the signed-in user is a member of are included)
Conditional access (when scoping a conditional access policy to a group)
Restricting access to self-serve password reset
Restricting which users can do Azure AD Join and device registration
The following scenarios DO NOT supported nested groups:
App role assignment (assigning groups to an app is supported, but groups nested within the directly assigned group will not have access), both for access and for provisioning
Group-based licensing (assigning a license automatically to all members of a group)
Office 365 Groups
See the product feedback page and add your suggestions if you need something more complex than what AAD currently supports.
I have been struggling to find out what way to best manage access and allowing our techs to access our customers subscriptions and Azure resources, without giving them explicit rights as contributors or the likes on each subscription.
Now I bumped into the Privilege Identity Management feature (https://learn.microsoft.com/en-us/azure/active-directory/active-directory-privileged-identity-management-configure?toc=%2fazure%2factive-directory%2fprivileged-identity-management%2ftoc.json) and it seems like it would do exactly what I want. Just-in-time administrative access for example.
Now with how the CSP access to our customer's subscriptions and Azure tenant is set up providing access via the AdminAgent/TenantAdmin group on the customer's subscription. I can only implicitly see them from our tenant or when I'm not explicitly in the customer's tenant. In other words they never show up in any lookups or dropdowns in our own Azure portal, I always have to state explicitly what tenant I want to access (portal.azure.com/tenant.onmicrosoft.com [I am really fine with this BTW]).
Can anyone tell me how they are doing this? I mean there must be some way of doing this that scales?
These two articles were very helpful in understanding how the CSP model is intended to work. The second one is especially interesting as it provides a way of achieving what I want but I would prefer a way without adding my users to the customer’s Azure AD. Something like the delegate admin access that is provided by the AdminAgent/TenantAdmin groups.
https://blogs.technet.microsoft.com/hybridcloudbp/2016/06/08/identity-and-rights-management-in-csp-model/
https://blogs.technet.microsoft.com/hybridcloudbp/2017/06/05/identity-and-rights-management-in-csp-model-part2/
But I feel there is so little info on this and where exactly is one supposed to look for help? I find being a CSP and looking for technical assistance not very comfortable.
Alternately, you could implement an IAM system to make it easier to
create/delete accounts for each customer or partner's users in appropriate
containers in your Azure AD (or any other directory for that matter).
This is a solution designed to do exactly this kind of B2B delegated management:
https://hitachi-id.com/solutions/identity-express-b2b.html
Today you can't really use Azure AD Privileged Identity Management (PIM) through the CSP model, for the reason you've identified: individual users from a CSP partner are not represented in the customer's Azure AD tenant, so you can't assign a PIM policy to them.
My suggestion here would be to reduce to a bare minimum the number of users who have admin access to your customer's tenant, and use them only for inviting the rest of the users needed from your tenant into the customer's tenant as B2B guest users. Once they're in the tenant, they can be given access to the Azure subscription one normally would (and they can use PIM to get that access just-in-time).
I'm quite new to all things MS/AD and coming from the app developer side of things so please bear with me if i'm not using the right terminology. I can't find confirmation in the online docs for this, so grateful for any ideas or links that could be helpful.
The scenario: my organization is a O365 shop and have a bunch of stuff in Azure. One project is a custom platform with several web apps. Most are accessed by our own folks via SSO, but some of these apps will be accessed by external users from our partners/vendors. A couple of these are MS shops but most are not and we can't require MS accounts.
The twist: we need to delegate user management to our partners/vendors. So as an example, for app3 we will have tons of partner/vendor organizations that need access. We want to give 1 person from that organization the responsibility of inviting their colleagues and removing folks when anyone leaves their organization. In many cases, they won't necessarily have the same email address domains so we can't restrict/group in that manner. In other cases, we need each national office of a global organization to have its own delegated admin to manage staff so there may be separate organizations with users that have the same email address domain.
My questions: Is Azure AD B2C the right approach for this?
Can it support this kind of delegated management (something like https://learn.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-self-service-group-management)?
Would we need configure a separate Azure AD B2C directories for each external organization or should these be groups within one Azure AD B2C directory?
At this time there is no out-of-the-box support for user management delegation in Azure AD B2C, whether it's delegatin user management to other B2C admins using local (.onmicrosoft.com) accounts or external users using local (#myemail.com) or social accounts. Azure AD B2C does not support self-service group management capabilities either. You can request either of these in the Azure AD B2C feedback forum.
Is the same instance of these apps going to support people from these multiple organizations?
If the answer is no, meaning that your are going to have one instance of the app for organization A, and another for organization B, you can definitely have multiple Azure AD B2C directories and wire up each application to each directory.
If a single instance of these apps will need to support multiple of these organization, then I can think of two options for you:
Use Azure AD B2C and build all the delegation and user management logic yourself. You can have a custom attributes to assign users their "organization" and another to indicate whether they can manage users or not. You would then need to create a user management UI that queries the Graph for all users that are in the same "organization" and let the user manage those. You would also need to build the invitation feature, first into this UI by creating the user through Azure AD Graph and setting its "organization" claim accordingly, and then by directing users to the Password Reset policy as their "account verification" flow.
Use Azure AD and the B2B collaboration feature (including its ability to delegate invitations). This also opens up the self-service group management capabilities you referenced. If you don't want these users to get access to other things in your organization, you would probably want to create a separate Azure AD tenant for this and also invite people from your on Azure AD via B2B collaboration.
Conceptually, B2C is meant for external users, and Azure AD is meant for internal users, with B2B complementing those internal users with partners that collaborate enough with those internal users to be almost thought of as internal users. That being said, use whichever one best suits your needs. Don't forget to keep in mind that their pricing model is very different.
We want to create a MVC web application using claims-based authentication, expecting roles as one of the claims. We want to Federate authentication providers using the Azure Access Control Service to manage this federation. One of the authentication providers is our Azure AD.
The problem is that Azure AD doesn't seem to be able to generate role (or even group) claims. What is the appropriate method to manage group or role access in Azure AD and have role claims served by Azure Access Control Service.
Thanks.
Edit:
A previous comment asked for details: We want to provide access to our cloud application to 3rd parties using their active directory (to simplify user management for them). Our application has a few levels of access to information that the 3rd parties can configure. We were hoping they could do this in their AD (based on our instructions). Groups seemed like the obvious choice, but if there is another way that works, as long as we can provide instructions, it'll work.
We want our application to get claims for a user's level of access. If we had only one partner that was using Azure AD, we could use the graph API against that endpoint, but with multiple partners changing over time, we wanted to federate them so our application only needs to trust the federation server. We were assuming that we needed Azure ACS to manage the federation.
AAD does support roles / groups and you can administer them from the Azure Portal.
Howeve, these are not passed in the "canned" set of claims.
You need to use the Graph API and then convert them e.g. Windows Azure Active Directory: Converting group memberships to role claims.
Update:
ACS requires something to federate with. You can't hook a customer AD up to ACS - you need something like ADFS on top of their AD.
I assume your cloud app. runs in Azure?
Then make your app. multi-tenanted. If your customers have their own Azure tenant, it will work. You just need to add the Graph API code to your app. ACS is not required.
Your customers then run DirSync. This keeps their Azure tenant in sync. with their AD changes.
So two options:
Customer does not have Azure tenant. They install ADFS and federate with AAD.
Customer's who do have Azure tenant use DirSync.
Good news: we have recently turned on the Application Roles and Groups Claim features in Azure AD.
Get a quick overview here: http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx
Deep dive post and video on app roles feature is here: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/
Deep dive post and video on app roles feature is here: http://www.dushyantgill.com/blog/2014/12/10/authorization-cloud-applications-using-ad-groups/
Hope that helps.
Groups aren't the best choice because they are unique within each directory. Unless you get your customers to define a set of groups that have well-known names and match against the strings, that is (the object IDs of a group is different per directory even if they have the same name). I'm actually from the Azure AD team and we are seriously considering releasing a feature to allow you to define roles in your app that your customers can assign their users to. Please stay tuned on this. In the meantime, unfortunately groups are the only way to go. You would have to call "GetMemberGroups" using the Graph to retrieve the groups that the user is assigned to.
What are your timelines for releasing this application? You can contact me directly to see if we can work with your scenario.