This short blog will be about a question I received on Linkedin. The question was about Graph Explorer and why it wasn’t returning the OMA-URI values configured. It only showed some nice **** (IsEncrypted Value)
![Afbeelding met tekst Automatisch gegenereerde beschrijving](https://call4cloud.nl/wp-content/uploads/2021/09/afbeelding-met-tekst-automatisch-gegenereerde-bes-20.png)
1. Replicating the Problem
If we want to fix the problem, we need to experience it ourselves. To start replicating the problem, I opened the graph explorer first.
Graph Explorer is an excellent tool for starting with creating Graph API requests and for checking some settings.
Let’s look at what settings are returned when we run this query.
![the graph response is now showing the isencrypted configured to true and with it the value is encrypted](https://call4cloud.nl/wp-content/uploads/2021/09/word-image-34.png)
As shown above, the value has some nice **** instead of the real values. So what’s happening?
2. What’s Happening?
When taking another good look at the screenshot above, you could also have noticed another funny setting: “IsEncrypted”: True
![the secr](https://call4cloud.nl/wp-content/uploads/2021/09/word-image-35.png)
Please Note: The Isencrypted and SecretReferencevalueid are only shown in the Beta version and not in the V1.0 of Graph.
I guess it’s obvious what “isencrypted” means when it’s configured to 1. If not… the official documentation says the value field is encrypted.
![](https://call4cloud.nl/wp-content/uploads/2021/09/word-image-36.png)
So, Microsoft has suddenly switched the default value of isencrypted to 1 last month? I guess I missed that announcement. But okay, no problem… Encryption is always a good thing. How are we going to decrypt it?
When looking at the outcome of the query, we also noticed the “Secretreferencevalueid” in it.
![Secretreferencevalueid can be used for looking up secret for decryption](https://call4cloud.nl/wp-content/uploads/2021/09/word-image-37.png)
Okay… So we can use this “id/key” to decrypt the oma settings value. But luckily there is no official documentation to tell us how?
![Afbeelding met tekst Automatisch gegenereerde beschrijving](https://call4cloud.nl/wp-content/uploads/2021/09/afbeelding-met-tekst-automatisch-gegenereerde-bes-21.png)
Looking back at the wonderful history of GitHub commits, I noticed the “isencrypted” and the needed “secretreferencevalueid” appeared in the commit from 14 April
![Afbeelding met tekst Automatisch gegenereerde beschrijving](https://call4cloud.nl/wp-content/uploads/2021/09/afbeelding-met-tekst-automatisch-gegenereerde-bes-22.png)
Okay, but how will we get back the URI we need? Fiddler to the rescue! When we need some more information about what happens when we configure Intune, we need to use Fiddler. If you want to know how it works, please visit this blog.
So what does the URI look like?
![](https://call4cloud.nl/wp-content/uploads/2021/09/word-image-38.png)
I guess we have everything we need now, let’s create a PowerShell script to get back the values ourselves.
PLEASE NOTE: Uploading new device configuration policies with PowerShell is totally not a problem, as long as you don’t add the “isencrypted” key etc. So when you have a backup of your Intune tenant and the “isencrypted” part is in it, remove it!
Take a look at my GitHub enrollment page for some examples
Enrollment/Windows10_TimeZone.json at main · Call4cloud/Enrollment (github.com)
3. Fixing the problem
We discussed the PowerShell script with everything in this blog. Please test it out yourself, but don’t forget to change the device configuration ID to your liking
$authResult = Get-MsalToken -ClientId 'd1ddf0e4-d672-4dae-b554-9d5bdfd93547' -Scopes 'https://graph.microsoft.com/.default'
$headers1b = @{
'Content-Type'='application/json'
'Authorization'="Bearer " + $authResult.AccessToken
'ExpiresOn'=$authResult.ExpiresOn
}
$deviceconfigid = "99b324ca-937e-4494-ac54-b06d889b04e8"
#get the device configuration
$url = "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations/$deviceconfigid"
$deviceconfiguration = Invoke-RestMethod -Uri $url -Headers $headers1b -Method get
#get the secretid needed to unencrypt the data
$secretid = $deviceconfiguration.omasettings.secretReferenceValueId
#parsing the secretid to unencrypt it
$Value = Invoke-restmethod -Headers $headers1b -Method get -uri "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations/$deviceConfigid/getOmaSettingPlainTextValue(secretReferenceValueId='$($secretid)')"
$value | fl
4. Application VS Delegated Permissions
The day after this blog, I received another question about this nice problem: “Why doesn’t it work with an App Registration”
First, we need to know the difference between the script I used and the script that didn’t work. Let’s take a look at the possible Graph Permissions.
![application permissions vs delegated permissions](https://call4cloud.nl/wp-content/uploads/2021/09/image-46.png)
So, when getting the token with the script I used, you will be using Delegated permissions because I am accessing it by signing in with a username/password and using the Microsoft Intune PowerShell App with the well-known d1ddf0e4-d672-4dae-b554-9d5bdfd93547 ID.
![](https://call4cloud.nl/wp-content/uploads/2021/09/image-47-1024x249.png)
When you use this script below, you are “Application Permissions” because it doesn’t prompt you to login but uses the clientid and clientsecret to login.
#Define Client Variables Here
#############################
$TenantName = "*****"
$clientID = "*****"
$clientSecret = "*******"
$Scope = "https://graph.microsoft.com/.default"
#Define deviceconfig here
#############################
$deviceconfigid = "99b324ca-937e-4494-ac54-b06d889b04e8"
#Construct Auth call to get Access Token
#########################################
$Body = @{
Grant_Type = "client_credentials"
Scope = $Scope
client_Id = $clientID
Client_Secret = $clientSecret
}
$authUri = "https://login.microsoftonline.com/$TenantName/oauth2/v2.0/token"
$TokenResponse =
Invoke-RestMethod -Uri $authUri -Method POST -Body $Body
$token = $tokenresponse.Access_token
There should normally be no difference, but the Application App PowerShell script will return a (403) Not authorized error when you try to retrieve the omasettings value.
![invoke-restmethod giving the 403 error not allowed](https://call4cloud.nl/wp-content/uploads/2021/09/image-48-1024x98.png)
Looking at it with Fiddler, you will notice a weird not googleable error: UnknownInConvertApiError
So we can assume that running the same script with a token with Delegated permissions works but it fails when running the same script with a token with Application permissions!
So what else can we do? If you want to automate the backup of your Intune tenant and you need to use an App Reg to do it, you could add a user for delegated permissions in the body.
$client_id = "*"
$client_secret = "*"
$tenant_id = "*"
$resource = "https://graph.microsoft.com"
$authority = "https://login.microsoftonline.com/$tenant_id"
$tokenEndpointUri = "$authority/oauth2/token"
$UserForDelegatedPermissions="*"
$Password="*"
$content = "grant_type=password&client_id=$client_id&client_secret=$client_secret&username=$UserForDelegatedPermissions&password=$Password&prompt=admin_consent&resource=$resource";
$response = Invoke-RestMethod -Uri $tokenEndpointUri -Body $content -Method Post -UseBasicParsing
$access_token = $response.access_token
$headers1b = @{
'Content-Type'='application/json'
'Authorization'="Bearer " + $Access_token
'ExpiresOn'=$response.Expires_On
}
Hopefully, we can get back a good answer as to why it isn’t working with Application Permissions… So stay tuned!
![](https://call4cloud.nl/wp-content/uploads/2021/09/image-49.png)
5. Microsoft has Fixed the Application Permissions Issue
Yes!!! Microsoft has fixed the problem with the UnknownConvertApiError when you want to return the encrypted OMA settings value.
![the functionality now seems to be working again with application permissions. So microsoft seems to have fixed it?](https://call4cloud.nl/wp-content/uploads/2021/10/image.png)
Of course, I did a test run myself… As shown below, it returned the proper values now!
![](https://call4cloud.nl/wp-content/uploads/2021/10/image-1-1024x188.png)
6. I guess Microsoft didn’t fix all the Application Permissions!
When you are using automation to get the device reports like mentioned in this MS Doc below, you are also going to end up with a nice new error
Use Graph APIs to export Intune Reports | Microsoft Docs
This is the code I used to generate the CSV for the device reports
#get the token
$token = Get-MsalToken -ClientId '*' -ClientSecret (ConvertTo-SecureString '*' -AsPlainText -Force) -TenantId '*' -Scope 'https://graph.microsoft.com/.default'
$headers1b = @{
'Content-Type'='application/json'
'Authorization'="Bearer " + $token.AccessToken
'ExpiresOn'=$token.ExpiresOn
}
#get the device configuration
$url = "https://graph.microsoft.com/beta/deviceManagement/reports/exportJobs"
$body =
@'
{"reportName":"Devices","filter":"(OwnerType eq '1')","localizationType":"LocalizedValuesAsAdditionalColumn","select":["DeviceName","managementAgent","ownerType","complianceState","OS","OSVersion","LastContact","UPN","DeviceId"]}
'@
$deviceconfiguration = Invoke-RestMethod -Uri $url -Headers $headers1b -Method post -body $body
And the error I got: CustomApiErrorPhrase .
![we got the CustomApiErrorPhrase when we automated the Intune device reports](https://call4cloud.nl/wp-content/uploads/2021/10/image-16-1024x88.png)
That’s not good at all. When you need the reports generated now, you could use the script I mentioned earlier to pass a user with credentials for the delegated permissions.
Conclusion:
When do I need to choose between spending my free evening watching some series or helping someone with a question I don’t have the answer to? (at that time)
![What You're Thinking When Painting | Steve zissou, Giphy, Zissou](https://call4cloud.nl/wp-content/uploads/2021/09/what-youand39re-thinking-when-painting-or-steve-zis.gif)
I guess you all know what my choice was.
Hey Rudy, thanks again for yesterday.
I’ve been following what you posted and works perfectly on my Graph Explorer, however I seem to be getting a error when running it on PowerShell (Invoke-restmethod : The remote server returned an error: (403) Forbidden.)
Which is odd as my App Registration has the same permissions as my Graph Explorer, any idea where I could be daft?
If needed I can provide my App Registration API Permissions export
That’s odd indeed.. You would expect a app registration could do the same, as it are intune device config policies. Could you show me your API persmissions export? So i can simulate it at my end?
Thanks Rudy, will post the output below. But let me know if you want the export file for easier readability.
Delegated Microsoft Graph Policy.ReadWrite.ConditionalAccess
Delegated Microsoft Graph Policy.Read.All
Delegated Microsoft Graph Agreement.Read.All
Delegated Microsoft Graph DeviceManagementConfiguration.Read.All
Delegated Microsoft Graph DeviceManagementConfiguration.ReadWrite.All
Delegated Microsoft Graph Reports.Read.All
Delegated Microsoft Graph Directory.Read.All
Delegated Microsoft Graph Directory.AccessAsUser.All
Delegated Microsoft Graph Application.Read.All
Delegated Microsoft Graph ServiceHealth.Read.All
Application Microsoft Graph Policy.ReadWrite.ConditionalAccess
Application Microsoft Graph Device.ReadWrite.All
Application Microsoft Graph Directory.ReadWrite.All
Application Microsoft Graph ServiceMessage.Read.All
Application Microsoft Graph Group.ReadWrite.All
Application Microsoft Graph DeviceManagementServiceConfig.ReadWrite.All
Application Microsoft Graph Organization.ReadWrite.All
Application Microsoft Graph DeviceManagementConfiguration.Read.All
Application Microsoft Graph DeviceManagementManagedDevices.ReadWrite.All
Application Microsoft Graph Organization.Read.All
Application Microsoft Graph Policy.Read.All
Application Microsoft Graph DeviceManagementConfiguration.ReadWrite.All
Application Microsoft Graph ServiceHealth.Read.All
Application Microsoft Graph DeviceManagementApps.ReadWrite.All
Application Microsoft Graph Reports.Read.All
Application Microsoft Graph DeviceManagementRBAC.ReadWrite.All
Application Microsoft Graph Policy.ReadWrite.TrustFramework
That’s really odd
When using a token with delegated permissions it works, when making the exact same graph call using application permissions it will fail with a 403 error…
And as you are using an App reg… you could guess what’s using…
Thanks for the update Rudy,
I got a response from Microsoft on this and they gave me the same steps you did (only 3 weeks slower).
I queried the Application permissions now as I can’t use my Automation Scripts against multiple tenants with Application Authentication 🙂
Will update if I get an answer before you get one.
I can’t see the Secretreferencevalueid property in v1.0 endpoint ?
Any thoughts?
The v1.0 Endpoint doesn’t have the isencrypted part, you will need to switch to the beta to see it.
As mentioned in the blog, uploading a new device policy isn’t an issue as long as you don’t specify those 2 keys.
So I was able to fix my oma file upload in my automation runbooks again!
After Microsoft came back and said the encryption is not on v1.0 yet, I had a look at my json export and it had x2 lines under each omaURI setting:
“secretReferenceValueId”: “FullID”,
“isEncrypted”: true,
Removed these from a 5000 line json file and it uploaded against my tenants again.
So I am back up and running with my config baseline again.
Hi that’s totally correct, uploading a new device config isn’t a problem so long you remove those 2 specific lines indeed. Just like I am showing at my githnb page
https://github.com/Call4cloud/Enrollment/blob/main/DU/JSON/Windows10_TimeZone.json
Great article, however I’m running into the following error when I run it, I’ve checked I my account has rights on the Enterprise App “Microsoft Intune PowerShell” which it does,
AADSTS50011: The redirect URI ‘https://login.microsoftonline.com/common/oauth2/nativeclient’ specified in the request does not match the redirect URIs configured for the application ‘d1ddf0e4-d672-4dae-b554-9d5bdfd93547’. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.
Anyone else had this or any ideas how to fix it?