Identity in Azure

ADFS – used for Federation Trust Only

AD Connect – Used for Sync of on prem to Azure

• Azure ADDS  = Used to provide all Domain Services without fully deployed DCs in Azure
• Azure AD Domain Services integrates with your existing Azure AD tenant, thus making it possible for users to log in using their corporate credentials. Additionally, you can use existing groups and user accounts to secure access to resources, thus ensuring a smoother ‘lift-and-shift’ of on-premises resources to Azure Infrastructure Services.
• Azure AD Domain Services functionality works seamlessly regardless of whether your Azure AD tenant is cloud-only or synced with your on-premises Active Directory.

Keep credentials out of code: Introducing Azure AD Managed Service Identity

Your code needs credentials to authenticate to cloud services, but you want to limit the visibility of those credentials as much as possible. Ideally, they never appear on a developer’s workstation or get checked-in to source control. Azure Key Vault can store credentials securely so they aren’t in your code, but to retrieve them you need to authenticate to Azure Key Vault. To authenticate to Key Vault, you need a credential! A classic bootstrap problem. Through the magic of Azure and Azure AD, MSI provides a “bootstrap identity” that makes it much simpler to get things started.

Here’s how it works! When you enable MSI for an Azure service such as Virtual Machines, App Service, or Functions, Azure creates a Service Principal for the instance of the service in Azure AD, and injects the credentials (client ID and certificate) for the Service Principal into the instance of the service. Next,

1. Your code calls a local MSI endpoint to get an access token
2. MSI uses the locally injected credentials to get an access token from Azure AD
3. Your code uses this access token to authenticate to an Azure service

Managed Identities

There are two types of managed identities:

• A system-assigned managed identity is enabled directly on an Azure service instance. When the identity is enabled, Azure creates an identity for the instance in the Azure AD tenant that’s trusted by the subscription of the instance. After the identity is created, the credentials are provisioned onto the instance. The lifecycle of a system-assigned identity is directly tied to the Azure service instance that it’s enabled on. If the instance is deleted, Azure automatically cleans up the credentials and the identity in Azure AD.
• A user-assigned managed identity is created as a standalone Azure resource. Through a create process, Azure creates an identity in the Azure AD tenant that’s trusted by the subscription in use. After the identity is created, the identity can be assigned to one or more Azure service instances. The lifecycle of a user-assigned identity is managed separately from the lifecycle of the Azure service instances to which it’s assigned.

Azure Resource Manager

is just a managed identity

 

Service Principal  – an object in AAD (just like Application Object)

• Consider the application object as the global representation of your application for use across all tenants, and the service principal as the local representation for use in a specific tenant.
• The application object serves as the template from which common and default properties are derived for use in creating corresponding service principal objects. An application object therefore has a 1:1 relationship with the software application, and a 1:many relationships with its corresponding service principal object(s).
• A service principal must be created in each tenant where the application is used, enabling it to establish an identity for sign-in and/or access to resources being secured by the tenant. A single-tenant application has only one service principal (in its home tenant), created and consented for use during application registration. A multi-tenant Web application/API also has a service principal created in each tenant where a user from that tenant has consented to its use.
• – does not allow access to a VM , but can manage resources attached to the VM

 

The Need for Azure ADDS

key aspect of migrating on-premises applications to Azure is handling the identity needs of these applications. Directory-aware applications may rely on LDAP for read or write access to the corporate directory or rely on Windows Integrated Authentication (Kerberos or NTLM authentication) to authenticate end users. Line-of-business (LOB) applications running on Windows Server are typically deployed on domain joined machines, so they can be managed securely using Group Policy. To ‘lift-and-shift’ on-premises applications to the cloud, these dependencies on the corporate identity infrastructure need to be resolved.

Administrators often turn to one of the following solutions to satisfy the identity needs of their applications deployed in Azure:

• Deploy a site-to-site VPN connection between workloads running in Azure Infrastructure Services and the corporate directory on-premises.
• Extend the corporate AD domain/forest infrastructure by setting up replica domain controllers using Azure virtual machines.
• Deploy a stand-alone domain in Azure using domain controllers deployed as Azure virtual machines.

All these approaches suffer from high cost and administrative overhead. Administrators are required to deploy domain controllers using virtual machines in Azure. Additionally, they need to manage, secure, patch, monitor, backup, and troubleshoot these virtual machines. The reliance on VPN connections to the on-premises directory causes workloads deployed in Azure to be vulnerable to transient network glitches or outages. These network outages in turn result in lower uptime and reduced reliability for these applications.

Options – Replica AD on Azure – or Standalone AD in Azure

Introducing Azure AD Domain Services

Azure AD Domain Services provides managed domain services such as domain join, group policy, LDAP, Kerberos/NTLM authentication that are fully compatible with Windows Server Active Directory. You can consume these domain services without the need for you to deploy, manage, and patch domain controllers in the cloud. Azure AD Domain Services integrates with your existing Azure AD tenant, thus making it possible for users to log in using their corporate credentials. Additionally, you can use existing groups and user accounts to secure access to resources, thus ensuring a smoother ‘lift-and-shift’ of on-premises resources to Azure Infrastructure Services.

Azure AD Domain Services functionality works seamlessly regardless of whether your Azure AD tenant is cloud-only or synced with your on-premises Active Directory.

Privileged Identity Management with RBAC (requires Azure AD P2 Premium License)

• See which users are admins in AAD and which users have privileged roles; get alerted about changes / additions to Admin users
• Can manage the access for built in roles to enable on demand, just in time access to azure resources
• get alerts when new users are assigned resource access
• want to minimize the number of people who have access to secure information or resources, because that reduces the chance of a malicious actor getting that access, or an authorized user inadvertently impacting a sensitive resource. However, users still need to carry out privileged operations in Azure AD, Azure, Office 365, or SaaS apps. Organizations can give users just-in-time (JIT) privileged access to Azure resources and Azure AD

Identity Tokens – SAML vs JWT

Claims can be part of SAML token or JWT token.

Claims contain username etc.

Azure AD B2C supports the OAuth 2.0 and OpenID Connect protocols, which makes use of tokens for authentication and secure access to resources.

All tokens used in Azure AD B2C are JSON web tokens (JWTs) that contain assertions of information about the bearer and the subject of the token.

Azure AD Identity Protection vs. Priv. Identity

Compromised accounts disabled ASAP – AAD Identity Protection – Key Authentication Requirement

Single vs Multi Tenant AAD Apps

Any APP that needs to use AAD must be registered as an AAD tenant.

When it comes to developing apps, developers can choose to configure their app to be either single-tenant or multi-tenant during app registration in the Azure portal.

• Single-tenant apps are only available in the tenant they were registered in, also known as their home tenant.
• Multi-tenant apps are available to users in both their home tenant and other tenants.

Accounts in this directory only – Single tenant
All user and guest accounts in your directory can use your application or API.
Use this option if your target audience is internal to your organization.

Accounts in any Azure AD directory – Multi-tenant
All users and guests with a work or school account from Microsoft can use your application or API. This includes schools and businesses that use Office 365.
Use this option if your target audience is business or educational customers.

Accounts in any Azure AD directory and personal Microsoft accounts (such as Skype, Xbox, Outlook.com) – Multi-tenant
All users with a work or school, or personal Microsoft account can use your application or API. It includes schools and businesses that use Office 365 as well as personal accounts that are used to sign in to services like Xbox and Skype.
Use this option to target the widest set of Microsoft accounts.

AAD SSO

AAD Basic – has SSO and self service password reset

AAD P1 and P2 _

AAD Free – No Self Service Password

 

RBAC

Contributor and Co-Admin DO NOT have Billing Rights

OWNER has billing and Usage Reports Rights