The need for Identity
For any service, it’s critical to be able to apply the principle of least privilege. This requires granting certain actions (roles) to certain security principals at a defined scope. We are focusing on security principles. Any actor should be uniquely identifiable. A central store for the identities is required along with capabilities to use them.
Enter… Azure AD
Azure AD is the identity provider for the Microsoft clouds like Azure, Microsoft 365, and Dynamics 365. Azure AD is not equivalent to AD in the cloud. There are different Azure AD SKUs and Licensing options.
How do you get Azure AD?
Azure AD is the directory service used by most Microsoft services including Office 365, Dynamics CRM, and even Azure subscriptions. It is managed through Azure or Office portal. You can create additional Azure AD instances and by default will be a
<name>.onmicrosoft.com. It can also have a custom domain.
Azure AD Objects
Azure AD objects like Users, Groups (Assigned/Dynamic), Enterprise Applications/Azure Resources (Services Principle) along with devices.
Authentication and Authorization
For Azure AD there is cloud and federated authentication using password hash(cloud), Pass-through Authentication PTA(hybrid), and Federation(hybrid) which in general in the same order. PTA/Federation has benefits related to locked accounts/logon hours/expired passwords. Authorization is against Azure AD.
Roles and Administrative units
There are many built-in roles related to Azure AD and Microsoft SaaS solutions. Roles can be given to users and a special type of group(cloud). Custom roles can be created if built-in do not meet requirements. While creating the roles you should always think about the least privileged. The Scope is normally global however Administrative Units can limit the scope of roles to the subset of users. mystaff.microsoft.com may be useful for simple management.
Privileged Identity Management
This enables the elevation of Azure AD (and ARM) roles when needed for limited time. Roles must be pre-assigned to be available for users. Users then elevate on-demand or for a future time. This is an Azure AD P2 feature.
Azure AD MFA
Passwords on their own are not good. MFA or Multi Fator Authentication blocks 99.9% of attacks. MFA can be something we know (pin/gesture0, something we are (biometric), or something we have(phone, token, laptop). It should be used sparingly or responding will become muscle memory.
3rd Part MFA
This is still evolving and today there are custom controls that integrate with conditional access. The new implementation will bring better integration including step-up authentication. To use Azure MFA from on-premise such as RADIUS there is an extension for NPS.
Securing registration and SSPR
MFA registration is combined with SSPR. There is a chicken & egg problem. Users must initially set up their security registration which would authenticate with password only. Then from conditional access – User actions – Register security information can lockdown.
This is triggered for any authorization regardless of the authentication method. It provides rich controls around users, roles, apps, environment, etc. It is an AAD P1+ feature.
B2C and B2C
Often we will have people in other companies we want to collaborate with and they can be invited into our AAD as B2B guests. B2C is aimed at our customers as a separate type and tenant instance that is fully customizable with other types of social identity support. There are changes coming in the future for more unification.
Very often people change roles, get new permission and never lose old permission. The access revies enables review on group membership, app assignment, and role assignment. The review can be by the administrator, delegated people, or self-review.
AD in Azure?
Good old AD DS is likely not going anywhere. Azure AD DS provides a managed AD with objects replicated from AAD (requires password hash sync). If you have existing AD typically extend that to Azure. VMs can be auto-joined to AD through extension(store creds in Key Vault)