Jul 202021
 

On a recent support case we had a customer who was trying to automate Privileged Identity Management (PIM) role assignments for Azure Resources with PowerShell. We could not find any public end to end documentation on the syntax to make this work. After some trial and error we found the following syntax works.

NOTE: PIM can assign both Azure AD roles and Azure resource roles so both scenarios are shown below. Additionally, make sure you have the latest version of AzureADPreview module installed.

Assigning Azure AD roles

For this scenario there is a public doc explaining the syntax which can be found at PowerShell for Azure AD roles in Privileged Identity Management . For roleDefinitionID you can also look these IDs up on Azure AD built-in roles doc

PowerShell code example:

### Azure AD PIM Example
Connect-AzureAD

$tenantID = "91ceb514-5ead-468c-a6ae-048e103d57f0"
$roleDisplayName = "Global Administrator"
$roleDefinitionID = (Get-AzureADMSRoleDefinition -Filter "DisplayName eq '$roleDisplayName'").Id
$targetuserID = (Get-AzureADUser -ObjectId User.Name@jasonfritts.me).ObjectId  # Replace user ID

$schedule = New-Object Microsoft.Open.MSGraph.Model.AzureADMSPrivilegedSchedule
$schedule.Type = "Once"
$schedule.StartDateTime = (Get-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")
$schedule.EndDateTime =  ((Get-Date).AddDays(1)).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")

# Create temporary eligible role assignment
Open-AzureADMSPrivilegedRoleAssignmentRequest -ProviderId 'aadRoles' -ResourceId $tenantID -RoleDefinitionId $roleDefinitionID -SubjectId $targetuserID -Type 'adminAdd' -AssignmentState 'Eligible' -schedule $schedule -reason "testing"

# Create temporary active role assignment
Open-AzureADMSPrivilegedRoleAssignmentRequest -ProviderId 'aadRoles' -ResourceId $tenantID -RoleDefinitionId $roleDefinitionID -SubjectId $targetuserID -Type 'adminAdd' -AssignmentState 'Active' -schedule $schedule -reason "testing"


Assigning Azure Resource Roles

For Azure Resource roles I could not find any end to end public doc examples but after trial and error the below steps were confirmed to work.

NOTE: The additional cmds compared to Azure AD role scenario are to convert ARM subscription IDs and ARM role IDs into their PIM resource IDs. For roleDefinitionID you can also look up built-in role IDs on Azure built-in roles doc if you are using custom roles, you can look these up in Azure Portal -> Subscription blade -> Access Control -> Roles

PowerShell code example:

## Azure Resource PIM Example
Connect-AzureAD

$subscriptionID = "ed6a63cc-c71c-4bfa-8bf7-c1510b559c72"
$roleDefinitionID = "b24988ac-6180-42a0-ab88-20f7382dd24c" #Built-in Contributor Role Definition ID example
$targetuserID = (Get-AzureADUser -ObjectId User.Name@jasonfritts.me).ObjectId  # Replace user ID


# Convert IDs to PIM IDs
$SubscriptionPIMID = (Get-AzureADMSPrivilegedResource -ProviderId 'AzureResources' -Filter "ExternalId eq '/subscriptions/$subscriptionID'").Id
$RoleDefinitionPIMID = (Get-AzureADMSPrivilegedRoleDefinition -ProviderId 'AzureResources' -Filter "ExternalId eq '/subscriptions/$subscriptionID/providers/Microsoft.Authorization/roleDefinitions/$roleDefinitionID'" -ResourceId $subscriptionPIMID).Id


$schedule = New-Object Microsoft.Open.MSGraph.Model.AzureADMSPrivilegedSchedule
$schedule.Type = "Once"
$schedule.StartDateTime = (Get-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")
$schedule.EndDateTime =  ((Get-Date).AddDays(1)).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")

# Create temporary eligible role assignment
Open-AzureADMSPrivilegedRoleAssignmentRequest -ProviderId 'AzureResources' -ResourceId $SubscriptionPIMID -RoleDefinitionId $RoleDefinitionPIMID -SubjectId $targetuserID -Type 'adminAdd' -AssignmentState 'Eligible' -schedule $schedule -reason "testing"

# Create temporary active role assignment
Open-AzureADMSPrivilegedRoleAssignmentRequest -ProviderId 'AzureResources' -ResourceId $SubscriptionPIMID -RoleDefinitionId $RoleDefinitionPIMID -SubjectId $targetuserID -Type 'adminAdd' -AssignmentState 'Active' -schedule $schedule -reason "testing"

Jun 032021
 

Occasionally you may be alerted to an existing Azure AD service principal whose client secret is scheduled to expire soon. From the Azure AD portal -> Application Registrations -> App -> Certificates & Secrets blade it is not possible to extend the expiration of an existing secret. You can only create a new one.

This can be a problem because the portal auto-generates the secret to be a random value. So you would have to go and update all your application code\configs to use this new secret value.

Luckily, with Azure PowerShell module you can both create a new secret with the same value as your existing one and set it’s expiration date manually preventing any unnecessary work to update application code\configs.

Example Script:


# Get service principal
$sp = Get-AzADServicePrincipal -DisplayName "MyTestApp"

# View current password Ids and expirations
Get-AzADSpCredential -ObjectId $sp.Id

#choose expiration date
$start = get-date
$end = $start.AddYears(150)

#Set same password as current password
$SecureStringPassword = ConvertTo-SecureString -String "c0[Ndh_@G/j8tB4aqbq66R]P*0MVwB.h" -AsPlainText -Force
New-AzADAppCredential -ApplicationId $sp.ApplicationId -StartDate $start -EndDate $end -Password $SecureStringPassword

# Verify new credential expiration
Get-AzADAppCredential -ApplicationId $sp.ApplicationId
Aug 042020
 

Occasionally we receive support cases from customers performing audits of their Azure AD Audit or Sign in logs and do not know what the service principal \ actor ” Microsoft Approval Management “ is.

After review with Microsoft product engineering teams it was confirmed this is a 1st Party Microsoft Service Principal for the following services and may be logged in customer audit logs during the operation of any of these services in your tenant.

  1. Dynamic Groups
  2. Self Service Group Management
  3. O365 Group Expiration policy

Any of the operations performed by these services such as calculating group memberships, applying group memberships, performing group expirations etc.  will be logged in Azure AD audit logs as being performed by “Microsoft Approval Management”.  All of the operations performed by these services, are documented in the links above.

You can confirm this service principal is in your AAD tenant with the AzureADPreview PowerShell module and the following cmd

Get-AzureADServicePrincipal -Filter "DisplayName eq 'Microsoft Approval Management'" | fl *

Where you should confirm that the PublisherName = “Microsoft Services” and you may find it listed with the AppID of “65d91a3d-ab74-42e6-8a2f-0add61688c74” or “38049638-cc2c-4cde-abe4-4479d721ed44”

UPDATE:

If this service principal is disabled you may experience strange behavior in the Azure AD Portal when trying to manage groups.

One example, if this service principal has been disabled by the AAD Global Administrator any operation on groups in the AAD portal may return an error : “Unable to complete due to service connection error. Please try again later”

Portal error : Unable to complete due to service connection error. Please try again later.

If you receive this error, verify that the Microsoft Approval Management enterprise application has not been disabled.

  1. Go to AAD -> Enterprise Apps blade : Enterprise applications – Microsoft Azure
  2. Then browse to All applications Set filters to Application type = All Applications, Status = Any, Application Visibility = Any In search box type the appID 65d91a3d-ab74-42e6-8a2f-0add61688c74

3. Open this app’s properties Choose Enabled for users to sign in = Yes Hit Save

4. Then retry their group operation which failed

NOTE: You may also want to check for app ID 38049638-cc2c-4cde-abe4-4479d721ed44 to verify it is enabled as well.

UPDATE:
If you have other unknown principals showing up in your AAD logs and you would like to verify they are Microsoft 1st party principals please use the Feedback sections of the below articles

Unknown Actors in AAD Audit Reports
Verify first-party Microsoft applications in sign-in reports

Aug 042020
 

We have received a few cases in AAD Audit Log support topic around AAD audit logs showing a service principal named “Microsoft Substrate Management” has created users in their AAD tenant and they have no idea who this principal is.

UPDATE:
If you have other unknown principals showing up in your AAD logs and you would like to verify they are Microsoft 1st party principals please use the Feedback sections of the below articles

Unknown Actors in AAD Audit Reports
Verify first-party Microsoft applications in sign-in reports

You can find this service principal in your tenant using AzureADPreview Powershell module and the following cmd:

Get-AzureADServicePrincipal -Filter "DisplayName eq 'Microsoft Substrate Management'" | fl *

Where you should be able to confirm this is a 1st Party principal (PublisherName = Microsoft Services) with AppID = 98db8bd6-0cc0-4e67-9de5-f187f1cd1b41



After investigation, it was determined that the “Microsoft Substrate Management” service principal is a 1st party service principal used by Exchange Online during dual write operations to AAD. When for example a mailbox is created directly in Exchange Online, this service principal may show up in your audit logs as the actor who created the user account the mailbox will be assigned to.

More information on dual write operations in Exchange Online can be referenced at https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-improvements-to-accelerate-replication-of/ba-p/837218

For a better picture of the actor who initiated the request in Exchange Online, you will need to search the Office 365 Unified Audit Log in the timeframe of the activity via steps mentioned in the following articles:
https://docs.microsoft.com/en-us/office365/securitycompliance/search-the-audit-log-in-security-and-compliance#search-the-audit-log

Hope this helps someone!

Jul 162020
 

The following are my notes for setting up Azure AD B2B Direct Federation with a GSuite domain. The official documentation can be referenced at https://docs.microsoft.com/en-us/azure/active-directory/b2b/direct-federation. Note that if you only want to invite Gmail.com users you can use Google Federation steps instead https://docs.microsoft.com/en-us/azure/active-directory/b2b/google-federation

Steps to configure AAD B2B Direct Federation with GSuite Domain

  1. Login to https://admin.google.com -> Security -> Set up single sign-on (SSO) for SAML applications

  1. Choose Download Metadata, and save the returned GoogleIDPMetadata.xml locally

  1. Browse to https://portal.azure.com -> Azure AD -> External Identities -> All identity providers -> New SAML/WS-Fed IdP .  Choose protocol = SAML, domain name = gSuite domain name, method = parse metadata file.  Browse to your GoogleIDPMetadata.xml file and hit parse, then save:

  1. From https://support.google.com/a/answer/6363817?hl=en  follow Step 3. “Set up Google as a SAML identity provider (IdP)” and Browse to https://admin.google.com -> Apps -> SAML Apps -> New App
  1. Filter existing apps by “Microsoft Office 365” and add the app
  2. Download Metadata locally to .XML file
  3. Save
  4. Browse back to apps and choose “Microsoft Office 365”
  5. Edit Attribute Mapping to be as follows
     
IDPEmail* Basic Information Primary Email
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent Basic Information Primary Email
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress Basic Information Primary Email
  1. From https://support.google.com/a/answer/6363817?hl=en  follow Step 4. “Enable the Office 365 app” and Choose Edit Service -> Service Status -> ON for everyone
  1. Lastly Invite the Guest GSuite domain User from Azure AD
    1. Now From Azure AD portal -> Invite New User -> Invite a user from G Suite domain
    2. G Suite user gets invite email, and clicks redemption link and signs in with G Suite credentials to redeem invite successfully

Apr 072020
 

We occasionally get support cases from customers who when browsing to their Azure Portal’s subscription blade see a subscription type with a strange name “Access to Azure Active Directory” and get strange errors like “Unknown” role or “Unauthorized” or “Unable to access data” or “The current subscription does not allow you to perform any actions on Azure resources. Use a different subscription.”

TLDR: These subscriptions do NOT host Azure AD. These are legacy subscriptions that can no longer be managed by customer portal. If causing issues they are safe to delete but can only be deleted via support ticket today. For more info read below details.

Examples:

Access to Azure Active Directory Subscription example
Access to Azure Active Directory subscription errors examples

History of the Access to Azure Active Directory subscription

The “Access to Azure Active Directory” subscriptions are a legacy subscription type that are no longer used.  They were used prior to the current Azure Portal (https://portal.azure.com). 

At that time the classic Azure portal (https://manage.windowsazure.com) that was used to manage Azure Active Directory and other Azure resources only allowed access if the user had a Azure subscription associated to their user account. It utilized the classic Azure roles such as “Subscription Admin” \ “Billing Admin” \ and “Co-Administrator” only so you had to have one of these roles in order to login. It did not take into account Azure AD roles like Global Administrator etc.

This caused issues when the Azure AD admin didn’t have an Azure resource subscription necessarily, so these “dummy” subscriptions were created for such access.
 
You can read this blog post for a bit more history if you are interested:  https://techcommunity.microsoft.com/t5/Enterprise-Mobility-Security/Azure-AD-Mailbag-Azure-Subscriptions-and-Azure-AD/ba-p/249661 which describes the need for these subscriptions and how admins would get one assigned to them when needed.

Today no such access subscription is required as we now separate AAD RBAC permissions (Global Administrator etc) and Azure Resource subscription RBAC permissions (Owner, Contributor, Reader etc) and do not limit user’s access to https://portal.azure.com.

How to delete the Access to Azure Active Directory subscription

If these subscriptions are causing you problems, or you would just like to cleanup your Azure environment from unneeded subscriptions you can get these subscriptions removed from your account by opening a support case and requesting the subscription be deleted. Unfortunately, as the errors suggest these subscriptions cannot be managed using the current Azure Portal.

These subscriptions do not host any data and removing them will have no impact to your Azure Active Directory tenant, data, users, groups, or other subscriptions.

Hope this helps someone!

Dec 162019
 

I recently received a support case where the customer was concerned that a bad actor “fim_password_service@support.onmicrosoft.com” was performing SSPR \ Password Reset operations on their Azure AD user’s without authorization.


UPDATE:
If you have other unknown principals showing up in your AAD logs and you would like to verify they are Microsoft 1st party principals please use the Feedback sections of the below articles

Unknown Actors in AAD Audit Reports
Verify first-party Microsoft applications in sign-in reports

When checking the Azure AD Audit Logs, they found entries similar to the below screenshot:

fim_password_service@support.onmicrosoft.com AAD audit log entries

This is concerning as the customer has no account in their AAD tenant with the UPN fim_password_service@support.onmicrosoft.com.

We performed a reproduction of a standard SSPR operation performed by a known user, and confirmed that these logs appeared and are to be expected.

A successful SSPR operation will first show the user who performed SSPR performing verification steps, submitting a new password, and then the fim_password_service@support.onmirosoft.com service account resetting the user’s password as seen in the below example:

Reproduction of a successful SSPR by user testsspr@jasonfritts.me

If you expand your audit log search for all operations with the target account specified, you will see that the user who actually initiated the SSPR action is also audited.

We found it odd that this service account was performing the actual password reset so there was an escalation opened with our engineering team to review. They confirmed the same, that this is to be expected.

fim_password_service@support.onmicrosoft.com is an internal account used to indicate password reset is done in App context versus App + User context.

This means that as the user doesnt know their password, the reset operation can’t be completed in the context of the SSPR app + User, so in certain scenarios such as SSPR, AAD operations are performed in the App context only and thus are audited as the actor being the internal account fim_password_service@support.onmicrosoft.com. There are also other various AAD scenarios that may be audited like this as well such as certain MFA registration operations.

The engineering team acknowledged that this can be confusing to customers and they are working on publicly documenting this account to prevent future support cases in the future. I’ll be sure to update with a link when that occurs.

Hope this answers someone’s questions in the meantime!

Sep 262019
 

The Azure AD support team has received a number of support requests from customers looking for information on a curiously named Enterprise App \ Service Principal found in Azure Active Directory.

The service principal’s name is “P2P Server”. Understandably, customers are worried that this may evidence of some type of malware running in their Azure environment.

P2P Server app as found in Azure AD Enterprise Applications blade

After some digging and investigation, it was determined that this service principal is automatically registered in Azure AD after a Windows device has been successfully joined to Azure AD. This service principal enables a specific type of certificate based RDP authentication to take place called PKU2U authentication for DJ++ and AADJ devices. Using this principal, Windows devices that are Azure AD joined will provision device certificates in their computer store with a name matching “MS-Organization-P2P-Access” that enables RDP using Azure AD credentials. Via PKI, these certificates trust the tenant root certificate that is registered on the “P2P Server” service principal in Azure AD.

Full details on this certificate and how it is used can be referenced in our public doc https://docs.microsoft.com/en-us/azure/active-directory/devices/faq#qwhat-are-the-ms-organization-p2p-access-certificates-present-on-our-windows-10-devices

Snippet from this doc below

Q:What are the MS-Organization-P2P-Access certificates present on our Windows 10 devices?

A: The MS-Organization-P2P-Access certificates are issued by Azure AD to both, Azure AD joined and hybrid Azure AD joined devices. These certificates are used to enable trust between devices in the same tenant for remote desktop scenarios. One certificate is issued to the device and another is issued to the user. The device certificate is present in Local Computer\Personal\Certificates and is valid for one day. This certificate is renewed (by issuing a new certificate) if the device is still active in Azure AD. The user certificate is present in Current User\Personal\Certificates and this certificate is also valid for one day, but it is issued on-demand when a user attempts a remote desktop session to another Azure AD joined device. It is not renewed on expiry. Both these certificates are issued using the MS-Organization-P2P-Access certificate present in the Local Computer\AAD Token Issuer\Certificates. This certificate is issued by Azure AD during the device registration process.

Hopefully this answers someones questions on the source and purpose of the “P2P Server” service principal in Azure AD and the “MS-Organization-P2P-Access” certificate found on Azure AD joined Windows devices.

Thanks for reading!

Jul 152019
 

On a recent support case a customer wished to assign Azure AD Graph API permissions to his Managed Service Identity (MSI). If this was a standard Application Registration, assigning API permissions is quite easy from the portal by following the steps outlined in Azure AD API Permissions. However, today Managed Service Identities are not represented by an Azure AD app registration so granting API permissions is not possible in the Azure AD portal for MSIs.

Luckily, this is possible with the Azure AD and Azure PowerShell modules as well as Azure CLI shown via my colleague Liam Smith’s code samples below:

UPDATED 2020-11-30: Updated to assign graph.microsoft.com app roles instead of the legacy graph.windows.net. Reference https://docs.microsoft.com/en-us/graph/permissions-reference#microsoft-graph-permission-names for list of app roles

Assigning via PowerShell

#First define your environment variables
$TenantID="91ceb514-5ead-468c-a6ae-048e103d57f0"
$subscriptionID="ed6a63cc-c71c-4bfa-8bf7-c1510b559c72"
$DisplayNameOfMSI="AADDS-Client03"
$ResourceGroup="AADDS"
$VMResourceGroup="AADDS"
$VM="AADDS-Client03"

#If your User Assigned Identity doesnt exist yet, create it now
New-AzUserAssignedIdentity -ResourceGroupName $ResourceGroup -Name $DisplayNameOfMSI

#Now use the AzureAD Powershell module to grant the role
Connect-AzureAD -TenantId $TenantID #Connected as GA
$MSI = (Get-AzureADServicePrincipal -Filter "displayName eq '$DisplayNameOfMSI'")
Start-Sleep -Seconds 10
$GraphAppId = "00000002-0000-0000-c000-000000000000" #Windows Azure Active Directory aka graph.windows.net, this is legacy AAD graph and slated to be deprecated
$MSGraphAppId = "00000003-0000-0000-c000-000000000000" #Microsoft Graph aka graph.microsoft.com, this is the one you want more than likely.
$GraphServicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$MSGraphAppId'"
$PermissionName = "Directory.Read.All"
$AppRole = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName -and $_.AllowedMemberTypes -contains "Application"}
New-AzureAdServiceAppRoleAssignment -ObjectId $MSI.ObjectId -PrincipalId $MSI.ObjectId -ResourceId $GraphServicePrincipal.ObjectId -Id $AppRole.Id  

#NOTE: The above assignment may indicate bad request or indicate failure but it has been noted that the permission assignment still succeeds and you can verify with the following command
Get-AzureADServiceAppRoleAssignment -ObjectId $GraphServicePrincipal.ObjectId | Where-Object {$_.PrincipalDisplayName -eq $DisplayNameOfMSI} | fl

At this point you should have been able to verify that your identity’s service principal has the correct app roles as shown below.

Get-AzureADServiceAppRoleAssignment showing that MSI principal has assigned AppRoleAssignment

You can now perform some tests to verify permissions via the following code on your Azure Virtual Machine that has the service identity assigned to it:

# First grab a bearer token for the Graph API using IMDS endpoint on Azure VM
$response = Invoke-WebRequest -Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://graph.microsoft.com' -Method GET -Headers @{Metadata="true"}
$content = $response.Content | ConvertFrom-Json 
$token = $content.access_token 

You can copy\paste the value of $token to https://jwt.io to verify that your token is showing the Directory.Read.All permission properly.

Output of pasting $token contents to https://jwt.io to verify Directory.Read.All role

If for some reason your $token does not show the Directory.Read.All permission, try rebooting your Azure Virtual Machine as it is possible a previous failed request for a bearer token was cached on your VM

Now, continue testing on your Azure VM by using this $token to make a call to Azure AD Graph API :

$output = (Invoke-WebRequest -Uri "https://graph.windows.net/myorganization/users?api-version=1.6" -Method GET -Headers @{Authorization="Bearer $token"}).content
$json = ConvertFrom-Json $output
$json.value

Your $json.value output should be the successful response of your Azure AD Graph API call. Hope this helps someone!

Assigning via Azure CLI

You can also perform the same steps using Azure CLI and CURL if this is your preferred management environment. See below for Liam’s steps via Azure CLI

#1) Get accesstoken:
accessToken=$(az account get-access-token --resource=https://graph.windows.net --query accessToken --output tsv)

#2) Define a variable for your tenantID
TenantID=mytenant.onmicrosoft.com

#3) Confirm access to graph.windows.net:
curl "https://graph.windows.net/$TenantID/users?api-version=1.6" -H "Authorization: Bearer $accessToken"

#4) Find your managed identity's object ID and assign to a variable (MSIObjectID)
az ad sp list --filter "startswith(displayName, 'MyUAI')" | grep objectId

MSIObjectID=d910d43b-8886-4bff-90bf-25ee0acb2314

#5) Find the service principal objectID (GraphObjectID) of the "Windows Azure Active Directory" principal in your directory,  also confirm the id of the Directory.Read.All oauth2Permission role is 5778995a-e1bf-45b8-affa-663a9f3f4d04 (DirectoryReadAll)
az ad sp list --filter "startswith(displayName, 'Windows Azure Active Directory')"

GraphObjectID=72405622-433d-4943-a5ad-11a4401d0bd3
DirectoryReadAll=5778995a-e1bf-45b8-affa-663a9f3f4d04

#6) Define your JSON payload
json={'"'id'"':'"'$DirectoryReadAll'"','"'principalId'"':'"'$MSIObjectID'"','"'resourceId'"':'"'$GraphObjectID'"'}

#7) Give permissions of 'Directory.Read.All' to the service prinicpal:
curl "https://graph.windows.net/$TenantID/servicePrincipals/$MSIObjectID/appRoleAssignments?api-version=1.6" -X POST -d "$json" -H "Content-Type: application/json" -H "Authorization: Bearer $accessToken"

#8) Verify with read operation
curl "https://graph.windows.net/$TenantID/servicePrincipals/$MSIObjectID/appRoleAssignments?api-version=1.6" -X GET -H "Content-Type: application/json" -H "Authorization: Bearer $accessToken"

#9) Now you can test on your resource which has managed identity to verify access
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://graph.windows.net' -H Metadata:true
accessToken=<accessToken>
curl 'https://graph.windows.net/mytenant.onmicrosoft.com/users?api-version=1.6' -H "Authorization: Bearer $accessToken"