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
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.
This feature has been renamed to SAML/WS-Fed identity provider (IdP) federation for Guest users.
This guide is for configuring a federation relationship with a GSuite domain so that you can invite B2B Guest users to your AAD tenant when those users do not have their own Azure AD work\school accounts. It is NOT intended for configuring a SAML federated domain in your Azure AD tenant for SAML Authentication of your own GSuite users. For that process review Scenario 1 in Azure AD and GSuite Federation Scenario Notes
Once the B2B External Identity SAML federation has been configured, you MUST invite the GSuite Users to your tenant via a B2B Guest Invitation by folllowing Add guest users to the directory Once invited, the guest users MUST visit one of the supported tenanted URLs such as https://portal.azure.com/resourcetenant.onmicrosoft.com as described in supported Sign-in endpoints for SAML/WS-Fed docs . If they try to sign in via any other method (for example IDP initiated sign in) they will receive an error of the form ‘The requested federation realm object ‘https://accounts.google.com/o/saml2?idpid=xxxxxx’ does not exist.’ , meaning they tried to sign in to a common endpoint like https://portal.azure.com or https://myapps.microsoft.com.
Steps to configure AAD B2B Direct Federation with GSuite Domain
Login to https://admin.google.com -> Security -> Authentication -> SSO with SAML Applications -> Download Metadata file
Choose Download Metadata, and save the returned GoogleIDPMetadata.xml locally
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:
Google Admin Portal -> Apps -> Web and Mobile Apps -> Microsoft Office 365 -> User Access -> EditUser Access -> ON for everyone
Lastly Invite the Guest GSuite domain User from Azure AD
Now From Azure AD portal -> Invite New User -> Invite a user from G Suite domain
G Suite user gets invite email, and clicks redemption link and signs in with G Suite credentials to redeem invite successfully
Finally, if needed you can manually configure GSuite Direct Federation using Azure AD Preview PowerShell module and example script below (note your GSuite metadata will be different)
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 exampleAccess 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.
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.
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.
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.
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:
#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 :
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"
While working with customers to enable LDAPS for their Azure AD Domain Services managed domain, we often have trouble performing a successful LDAPS Bind using the tool LDP.exe. Below are the troubleshooting steps to determine root cause.
Verify Network Connectivity
Always verify that the network connectivity to port 636 exists via DNS name and IP address before troubleshooting further.
1. Browse to https://portal.azure.com -> All Services (top left) -> Azure AD Domain Services -> <managed domain name> -> Properties blade. And verify the following attributes:
Secure LDAP = Enabled
Secure LDAP certificate thumbprint (copy and save for later)
3. Open PortQry UI and perform a verification on the Secure LDAP external IP address on TCP port 636 to verify you see the port LISTENING.
If network connectivity doesnt exist, verify that the AAD DS Network Security Group (NSG) is allowing inbound traffic from client workstation to AAD DS subnet on TCP\636
Test TCP 636 connectivity to public IP of AAD DS
4. Once network connectivity to the public IP of LDAPS on TCP\636 has been confirmed. Perform the same test, but use any DNS name you have registered for this public IP. Example: ldapstest.jasonfritts.me.
NOTE: The domain name will not necessarily resolve for an external client machine unless it has been registered by you or an admin manually. Example: jasonfritts.onmicrosoft.com will not resolve to my LDAPS public IP. I would need to manually register a record for ldapstest.jasonfritts.me to point to 137.117.71.1. For testing purposes in this example, I have updated my Windows HOSTS file to point jasonfritts.onmicrosoft.com to 137.117.71.1
5. Next verify that this certificate has been imported in the following locations on your workstation’s Computer certificate store
Open the certificates MMC snap-in to your Local Computer certificate store per instructions found here
Browse to the Trusted Root Certification Authorities\Certificates store and verify certificate with ” <aad ds domain name> ” is found listed.
Open Local Computer certificate MMC, Check Trusted Root Cert Store to verify AAD DS self-signed certificate is trusted by computer
Verify that certificate thumbprint matches LDAPS thumbprint found in portal
You can also verify this via an administrative PowerShell cmd prompt and cmds like:
PS C:\ cd cert:\\ PS Cert:\> get-childitem -Path ’53F65017E5614959824FA5147A8173CAF8662D73′ -Recurse
If this certificate is not found in this location, please use the More actions -> Import action to import your self-signed AAD DS LDAPS certificate into the Trusted Root Certificate store of your Computer cert store and then retry your LDP.exe connection.
Until the self-signed certificate is trusted by your local computer, LDP.EXE will result in the error “Error: <0x51>: Fail to connect to jasonfritts.onmicrosoft.com”.
LDP.exe: Error <0x51> Fail to connect to
You can then check the Windows Event Log on the client machine and you will find a Event in System log with Source = Schannel and EventID 36882 complaining about Certificate received from the remote server was issued by an untrusted certificate authority.
Windows System Event 36882 indicating received cert not trusted
6. Once the self-signed certificate has been added to your Computer’s Trusted Root Certificate Store, you will be able to
Connected via LDP.exe successfully
Connected, next bind via credentials
Bind with credentials of AAD DC Administrator
Once bound, use View -> Tree to view AD partitions
Occasionally customers utilize Azure AD service principals for automation of Azure AD management tasks. In this scenario, you must grant the service principal the necessary Azure AD directory role permissions to complete the task. This can be performed using AzureADPreview PowerShell module
# Connect with Azure AD Global Admin or user with permissions
Connect-AzureAD
# Find Azure AD role by built in name
$role = Get-AzureADMSRoleDefinition -Filter "DisplayName eq 'Security Administrator'"
# Find Azure AD service principal by display name
$sp = Get-AzureADServicePrincipal -Filter "DisplayName eq 'test123'"
# Assign Azure AD role to service principal
New-AzureADMSRoleAssignment -RoleDefinitionId $role.Id -PrincipalId $sp.ObjectId -ResourceScope "/"
NOTE: You can also now perform this directly from Azure AD Portal -> Roles and Administrators blade -> Role -> Add Assignments -> Select members -> Filter by service principal display name
