Jun 10 2020 05:03 AM - edited Jun 10 2020 05:08 AM
I'm hoping to gain an understanding why all Intune Graph resources and actions only allow Delegated permissions. This essentially means no unattended administration available, at least not App-only.
I can't figure out why it is like this. The Intune PowerShell SDK (i.e. Microsoft.Graph.Intune PowerShell gallery module) can be used unattended'ly, but the sample for this that is on GitHub is using ConvertFrom-SecureString | Out-File. That's not really secure, nor is sending plain text password to MS Graph (not referring to the sample with the latter comment, rather this: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc). So Application permissions, enabling Certificate (or Client Credential) authentication would be far superior.
Referenced sample script: https://github.com/microsoftgraph/powershell-intune-samples/tree/master/Authentication
Use cases that I'm particularly talking about are ones like resetPasscode, or remoteLock. We should be able to trigger these actions with an App Registration that has Application permissions. We could then script automatic reactions, such as remoteLock upon a particular Azure AD Sign-In event or risk detection.
Can somebody please tell me why Intune's Graph permissions are strictly only Delegated? This same issue applies to about every single thing an Admin might want to use MS Graph API's for. I wish there was a TON of focus in this area by Microsoft. If magically all of a sudden customer administrative automation was catered to, this would be a massive positive thing leading to mass embracement from customers. Right now, it sometimes seems like MS doesn't want customers automating things with unattended intention.
Thanks in advance.
Jun 10 2020 05:08 AM
SolutionJun 10 2020 07:27 AM
@Thijs Lecomte Thanks for the info, this is great.
I wonder how/when this will factor into the Intune PowerShell SDK. I suppose they Connect-MSGraph cmdlet from the module/SDK will just need to get some client credential flow functionality added.
Jun 10 2020 09:35 AM
Jun 10 2020 01:45 PM
Jun 10 2020 11:43 PM
Jun 11 2020 05:54 AM - edited Jun 11 2020 05:56 AM
@Thijs Lecomte Thanks very much for this.
https://github.com/JeremyTBradshaw/PowerShell/blob/master/.Modules/msGraphFunctions.psm1 - that is my module. It currently is setup to accommodate certificate authentication in the client credential flow. The functions are:
Get-MSGraphAccessToken
New-SelfSignedAzureADRegisteredAppCertificate
New-MSGraphQuery
For my example which is was failing, I'm I was getting an access token successfully, and then with New-MSGraphQuery can could successfully list devices using v1.0 or beta:
# list devices via v1.0:
>$q1 = New-MSGraphQuery -AccessToken $Token -API v1.0 -Method GET -Query deviceManagement/managedDevices
>$q1.value | select deviceName, model
deviceName model
---------- -----
HTPC-G1 Z390 I AORUS PRO WIFI
j_AndroidForWork_6/9/2020_10:12 PM ONEPLUS A5010
# list devices via beta:
>$q2 = New-MSGraphQuery -AccessToken $Token -API beta -Method GET -Query deviceManagement/managedDevices
>$Q2.value | select deviceName, model
deviceName model
---------- -----
HTPC-G1 Z390 I AORUS PRO WIFI
j_AndroidForWork_6/9/2020_10:12 PM ONEPLUS A5010
# fail to remoteLock via Beta:
>New-MSGraphQuery -AccessToken $Token -API beta -Method POST -Query deviceManagement/managedDevices/9e250f72-a995-401d-8e32-7edf7fdb2eba/remoteLock
Invoke-RestMethod : {
"error": {
"code": "No method match route template",
"message": "No OData route exists that match template ~/singleton/navigation/key/action with http verb GET for request
/DeviceFE/StatelessDeviceFEService/deviceManagement/managedDevices('9e250f72-a995-401d-8e32-7edf7fdb2eba')/microsoft.management.services.api.remoteLock.",
"innerError": {
"request-id": "01f99d16-88e2-4b2c-b053-0fbfaec43947",
"date": "2020-06-11T12:39:08"
}
}
}
At C:\Users\<myProfile>\GitHub\PowerShell\.Modules\msGraphFunctions.psm1:125 char:5
+ Invoke-RestMethod @QueryProps -OutVariable QueryResponse
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand
Upon crafting this reply, I noticed in the error "No OData route exists ....... with http verb GET for request". This made me realize my problem. I had hard-coded "Get" as the method in my New-MSGraphQuery function, where I should have set it to my parameter -Method's value ($Method).
Original, non-working code:
$QueryProps = @{
Headers = @{ Authorization = "Bearer $($AccessToken.access_token)" }
Uri = "https://graph.microsoft.com/$($API)/$($Query)"
Method = 'Get'
ContentType = 'application/json'
}
Fixed, working code:
$QueryProps = @{
Headers = @{ Authorization = "Bearer $($AccessToken.access_token)" }
Uri = "https://graph.microsoft.com/$($API)/$($Query)"
Method = $Method
ContentType = 'application/json'
}
Again, thanks very much! I still needed this post and your response to get me looking at the Beta reference instead of v1.0. It was only after that, that I could flush out this error in my script. The -Method parameter was added to the function after a while, and I must have gotten distracted in the process and forgot to actually incorporate the parameter into the script after declaring in my params block. All good now though!
Jun 11 2020 06:29 AM