Month: August 2019

Forcefully Revoke Azure AD User Session Access – Immediately

· 2 Comments ·

Sometimes it is critical to revoke a user’s Azure AD session for whatever reason it may be. You can always delete the user from Azure AD, however if the user is connected via PowerShell, the user’s token may not expire for a few more minutes, or maybe hours, depending on the token TTLs settings… So what can you do? You can forcefully revoke a user’s token session by using the following PowerShell cmdlet, “Revoke-AzureADUserAllRefreshToken“. Due to Microsoft’s ever changing Azure modules, I have tested this solution within the Azure Cloud Shell, and not on a local machine with PowerShell ISE with the AZ or RM modules.

First we need to identify which user will have its access revoked. Based off of the Revoke cmdlet, you will need to specify the “ObjectID” parameter, and the user’s ObjectID can be found within the Azure AD blade as seen below:

For additional information you can view the user’s access by executing the following cmdlet, “Get-AzRoleAssignment -ObjectId <>”

Once we have identified the user and its ObjectID, we first need to connect to Azure AD, this is done by running the following cmdlet, “Connect-AzureAD -TenantId <>“. With my experience you need to specify the TenantID. Once you have connected, and verified your device, you can now run the Revoke cmdlet, as seen below, the following cmdlet needs to be executed, “Revoke-AzureADUserAllRefreshToken -ObjectId <>“. The Revoke cmdlet will not provide any details if the operation was successful, however it will throw an error if something did not go right — yes, very helpful, right? 🙂

By running this Revoke cmdlet, the user has now lost all access to its Azure AD account and any active sessions, either via the Azure Portal UI, or PowerShell will be immediately revoked. 🙂

What’s an Azure Service Principal and Managed Service Identity?

· 1 Comment ·

One of the general recommendations I always suggest to customers and their environments it leverage Azure Managed Service Identities (or MSI) over the traditional Service Principal (SP). Of course, the question then becomes, well what is the difference? When should I use a Service Principal and when should I use a Managed Service Identity?

In short, the difference is pretty clear. However, let’s make sure we understand what a Service Principal is, and what are they intended for…

What is a Service Principal (SP)?

In Azure, and many cloud environments, Service Principals carry the most weight with regards to access to the environment. Service Principals are an identity created for the use of applications, hosted services and automated tools to access Azure resources. This access is and can be restricted by assigning roles to the service principal(s).

What is a Managed Service Identity (MSI)?

With Managed Identities, there are two types of identities, system-assigned managed identity and user-assigned managed identity.

  1. System-assigned Managed Identity: is created and enabled directly on an Azure service. When enabled, Azure will automatically create the identity for the instance within Azure AD and will ensure it is trusted by the subscription where the instance resides. After the Azure resource/instance is created, the system-assigned managed identity credentials are provisioned onto the instance. The lifecycle is also directly attached to the Azure instance/resource and cannot be shared with other resources. In other words, the managed identity is created within Azure AD when the resource is created, and similarly the managed identity is deleted from Azure AD when the associated resource is deleted.
  1. User-assigned Managed Identity: is created as a standalone Azure resource, where the managed identity is created by the Azure AD administrator. The managed identity is trusted within the subscription and can also be assigned and shared with multiple Azure resources. The lifecycle is not dependent on the Azure resource, in other words, when the Azure resource is deleted, the managed identity is not deleted until the Azure AD administrator manually deletes the identity.

With MSI’s Azure automatically rotates/rolls the credentials every 46 days, Microsoft provides a workflow diagram on how MSIs work with Azure VM’s and other various Azure resources. See the diagram below to understand the credential rotation workflow.

Source: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview

What is the difference?

In short, when considering to use an MSI (Managed Service Identity) or a SP (Service Principal), also consider using a MSI for the reasons below.

MSI’s, managed the creation and automatically roll over the service principal for you. This is done by Azure in the background and requires no human/customer intervention. These credentials are rotated/rolled over every 46 days, this is a default behaviour/policy.

Use an MSI when and where available. Azure continues to grow their list of MSI’s and which resources can work with MSI’s, you can find the list HERE.

 

 

For a complete overview on MSI’s please visit Microsoft’s documentation HERE.