Audit Logs for Azure Events


A common request when working with Microsoft Azure is, "How can I view audit logs to determine who made changes to the subscription(s) and the related Azure resources?" With the new Audit Logs feature now available in the Azure Preview Portal (https://portal.azure.com), keeping track of changes becomes easier than ever.

Before getting started, I would like to point out that Dushyant Gill has an excellent post in which he provides one way to answer three very important questions:

  1. Who has access to my subscriptions?
  2. What access does each specific user have to my subscription?
  3. Who gained (or lost) access to my subscriptions in the past n days?
In Dushyant's post, he describes a PowerShell module he wrote that makes it easy to generate reports which answer the above questions.
 
In this post, I will describe one approach for working with the new Azure Audit Logs to determine what changed, and also how to view logs related to the addition or removal of co-administrators. Along with the PowerShell module described in Dushyant's post, this should allow much more insights into the actions taken against an Azure subscription.

 

What Changed?

By opening the new Audit Logs blade in the Azure Preview Portal, you can view many of the events that occurred against the subscription.

 (click the image to enlarge)

The Audit Logs blade shows five key pieces of information for the list of operations:

  1. Operation name
  2. Level: Critical, Error, Warning, or Informational
  3. Status: Succeeded or Failed
  4. Resource
  5. Time
Note 1: You can use the Filter action at the top of the Audit Logs blade to modify the operations displayed.
 
Note 2: Audit logs are available for only the Azure resources available in the Azure Preview Portal and/or the Azure Resource Manager API.

Clicking on a specific operation will open additional blades to view more detailed information.

(click the image to enlarge)

 

The Detail blade will allow you to view key pieces of information such as who made the change, when the change was made, which Azure resource and resource group were affected, etc.

(click the image to enlarge)


If the change is related to a role assignment (i.e. adding a user to one of the new Role Based Access Control (RBAC) roles - Virtual Machine Contributor, Website Contributor, etc.), the Detail blade will show additional information to show the user added to the role. At the time of this writing, however, the user and role is displayed as a GUID and not the corresponding friendly name (e.g. the email address or role name). It is anticipated this will be cleaned up in a future update to the Azure Preview Portal. In the meantime, you can leverage a few Azure PowerShell cmdlets to piece together the relevant information.

In the Details blade, have a look at the PROPERTIES value. There are two key pieces of information here: the PrincipalId and the RoleDefinitionId.

(click the image to enlarge)

 

For the cmdlets below, you will need to switch to the Azure Resource Manager mode in Azure Powershell by executing the command below.  Azure PowerShell version 0.8.15 is used in this post, although the cmdlets below first appeared in version 0.8.14.

> Switch-AzureMode AzureResourceManager

 

To determine the role to which the user was assigned, use the Get-AzureRoleDefinition cmdlet. This cmdlet returns all of the role definitions, so you will need to search for the specific definition (the GUID after "roleDefinition") as indicated the PROPERTIES in the Detail blade.

> Get-AzureRoleDefinition | where { ($_.Id -like "*de139f84-1756-47ae-9be6-808fbbe84772" )}

(click the image to enlarge)

 

To get the user added to the role, use the Get-AzureAdUser cmdlet. For the -ObjectId parameter, use the PrincipalId value from the PROPERTIES in the Detail blade.

> Get-AzureADUser -ObjectId b458cfbc-a101-45c1-9575-1ec43aefcc45

  

(click the image to enlarge)

 

What about Co-Administrators and Management Certificates?

When it comes to permissions in Azure, there are three approaches that can be used: the co-administrator model, management certificates, and Role Based Access Control (RBAC). The co-administrator model has been the security model in working with Azure for quite some time. People other than the subscription owner that wanted to work with Azure could be granted access to the Azure subscription as a co-administrator. As a co-administrator, they could take any action they desired against any Azure service.  If non-interactive administrative access was needed, a management certificate could be added to the target subscription(s).

Going back to the earlier topic of what change was made and by whom - how can we tell when a co-administrator or management certificate was added to the subscription?

For management certificates, you can use the List Subscription Operations service management API call. There is an Operation Name parameter in the response that should include AddSubscriptionCertificate and RemoveSubscriptionCertificate for the respective action.

(click the image to enlarge)

 

An astute observer of the MSDN documentation for List Subscription Operations will notice there is no corresponding operation for co-administrators. To obtain information about co-administrators being added or removed from a subscription, we can leverage the new audit logs available in the Azure Preview Portal and Azure Resource Manager API. Co-administrators in the Azure Management Portal actually correspond to the Owner role available in the Azure Preview Portal (and thus Azure Resource Manager). Adding or removing a co-administrator via the Azure Management Portal creates an event with Azure Resource Manager that is then logged. However, as of the time of this writing, the addition or removal of co-administrators is not yet reported in the Azure Preview Portal's Audit Logs.

To get the audit logs related to the addition or removal of co-administrators, you can use the Get-AzureResourceProviderLog PowerShell cmdlet. This cmdlet retrieves the operations associated to a specific Resource Provider - in this case we would want operations against the Microsoft.Authorization provider. For example, to view the logs for a certain date range, you could execute a command similar to the following:

> Get-AzureResourceProviderLog -ResourceProvider "Microsoft.Authorization" -StartTime "2015-03-10" -EndTime "2015-03-11" -DetailedOutput

A screenshot of the output is below. In the screenshot you'll notice you can see the adminEmail and adminType for the user added via the Azure Management Portal.

(click the image to enlarge)

 

Another alternative is to use the ability to retrieve all of the authorization events starting from a specific date up until the current time:

> Get-AzureResourceProviderLog -ResourceProvider "Microsoft.Authorization" -StartTime "2015-03-11" -DetailedOutput

(click the image to enlarge)

 

 Note that there are currently at least two known bugs related to the displayed information:

  1. If the removed co-admin is an Azure AD user (as opposed to a Microsoft Account), the adminEmail is empty
  2. The Caller value is not populating

 

But Wait! There's More!!

The Get-AzureResourceProviderLog cmdlet shown above is just one of the new audit log cmdlets now available. It is easy to view the additional cmdlets by executing the following command:

> get-help get-*Azure*log*

 

Name Description
Get-AzureSubscriptionIdLog Gets the operations associated with the current subscriptionId
Get-AzureResourceProviderLog Gets the operations associated with a Resource Provider
Get-AzureResourceLog Gets the operations associated with a ResourceId
Get-AzureResourceGroupLog Gets the deployment log for a resource group
Get-AzureCorrelationIdLog Gets the operations associated with a CorrelationId.

 

Summary

The new Audit Logs feature in the Azure Preview Portal, combined with new Azure PowerShell cmdlets, make it easier than ever to have insights into the changes made to an Azure subscription. Together, with the module described in Dushyant Gill's post, many of the administrative actions taken against an Azure subscription and related resources are now easily viewable.

Please be sure you are using at least version 0.8.14 of the Azure PowerShell cmdlets - that's when the cmdlets mentioned in this post first appeared. You also need to remember to switch the mode to use the AzureResourceManager.

 


Comments (8)

  1. Barbara Beltrame says:

    Very useful content and very well explained. Thank you!

  2. Aaron Lawrence says:

    IMO, this is not a serious answer to an auditor's request for audit logs.

    It's possible that with a huge amount of development work, you could build a useful audit log from all this disparate data, but why would Microsoft make their customers do that? Why not simply provide a single "Azure Management Audit log" with all the significant events in it?

    We are answering a customer's security compliance request, and auditing of such significant events is required. An answer to "use powershell scripts as noted on this blog post" is not an answer at all.

  3. @Aaron – The Azure Preview Portal does provide a simple Audit Log section that does capture many significant events. Granted, there is much better info for Azure Resource Manager based services than there is for the older services. Thankfully many of the services have moved or are in the process of moving to Azure Resource Manager which will significantly improve this experience.

    Out of curiosity, what would make the experience better for you?

  4. Rahul Mohan says:

    Can the  job done by "List Subscription Operations " API be achieved through PowerShell.

    I need to get the details about the creation, deletion, stopping, deallocation of various azure services like

    VM, StorageAccount, Website and so on.

    kindly suggest.

  5. Aaron Lawrence says:

    @Michael – sorry I didn't come back earlier, but I'm revisiting audit logs again … same customer 🙂

    My suggestions to improve would be

    a) Audit events for login and logout – this doesn't seem to be available now, and is a basic auditor requirement

    b) Provide the equivalent of the information described here, with a user interface.

    As a platform provider, I guess Microsoft teams are used to provide APIs as the end result. But for auditing purposes, you want to provide the end user (an auditor) a functioning solution, not just pieces of the puzzle.

  6. Rodel says:

    Is there any list of all events that are recorded in Audit Logs? If yes, where can I find that list? Thanks in advance!

  7. Prashant Shah says:

    With AzureRM I would recommend to use following
    get-help get-*log | FT Name, Synopsis -AutoSize -Wrap

    1. Prashant Shah says:

      We have following different types of logs now
      Get-AzureRmAuthorizationChangeLog
      Get-EventLog
      Get-AppxLog
      Get-DtcLog
      Get-AzureWebsiteLog

Skip to main content