AAD

Azure Active Directory, or AAD, provides authentication, authorisation, single sign on and multi-factor authentication across Azure, Microsoft 365 and external services (via Apps). It's built for multi-tenancy, allowing permissions to be granted across tenants. On-premise Active Directory instances can be synchronised with Azure AD.

Note that Azure RBAC, which controls Azure RM permissions, is separate.

Compared to Active Directory

Multi-tenant, as opposed to single forest. There's no cross-domain trust.
Flat structure, as opposed to OUs forming an X.500 tree structure.
Queried via Microsoft Graph, not LDAP
Authentication is via SAML, OAuth, and WS-Fed; no need for AD FS. Kerberos is supported only via Azure Active Directory Domain Services (AD DS).
No Group Policy.

Concepts

Tenants (or Directories) are isolated instances of Azure AD. A single tenant can be shared between multiple Azure subscriptions.
Users are human users, either Cloud or Synced (via Azure AD Connect), Member or Guest (invited). They're identified by a User Principal Name.
Groups are collections of users and other groups which can have their members managed by any number of administrators.
Apps
- Application objects are application definitions, managed via App registrations.
- Service Principals are "instances" of an application, managed via Enterprise Applications. They can reference an application object in a different directory, allowing multi-tenancy.
Devices
Administrative Units allow organisation similar to Organisational Units, except that they can't be nested within one another. This feature enables "My Staff", delegating password resets and profile information changes to team leads or managers rather than a central service desk.
Roles define sets of permissions which can be granted to users.

Conditional access

Conditional access policies allow taking actions based on compliance with one or all of the (enabled) following conditions:

Individual users or members of certain groups
Requesting access to specific cloud apps.
Level of sign-in risk
Location

Controls applied:

Require MFA
Require compliant device
Require hybrid AAD joined device
Require approved client app
Require app protection policy
Requiring MFA app

These policies can be tested by being enabled only for reporting.

Access reviews

Under Identity governance administrators can create Programs comprising Access Reviews. These tie any number of reviewers and a schedule to any number of applications and groups. Reviewers will be presented with accounts which likely no longer need access to data, e.g. because they've not accessed it in a long time.

Identity protection

Identity protection provides detection of vulnerabilities and risk events (e.g. signing in from a new location) and notifications, workflows and analysis tools for processing them. Vulnerabilities include:

Unconfigured MFA
Unmanaged cloud applications (via Cloud Discovery)
Management of privileged identities

Risk events include:

Infected devices
Leaked credentials
Access from anonymous IPs
Access from suspicious IP addresses
Impossible travel events
Unknown locations

The assigned risk level for different events differs. These collectively form the account's risk level.

We can set the user and sign-in risk policies to e.g.:

Require MFA
Require password change

Licensing

Licenses allow access to different Microsoft 365 services, and can be assigned to either users or groups. Before assigning licenses, a user's usage location must be set to the country from which the user will spend most of their time using the product, used to determine the appropriate license cost.

Custom domain

By default all AAD tenants exist under a subdomain of onmicrosoft.com, but it's possible to replace it with your own fully-qualified domain. Domains ownership is validated via a TXT record.

Children

Backlinks