HTTP status code mismatch (Failing -Filter for Get-MgSecurityAlerts)

[helloitsliam]

When executing Get-MgSecurityAlerts with a -Filter, it returns all values, even though it should filter.

Command executed: Get-MgSecurityAlert -Filter "Title eq 'Activity from infrequent country'"

As requested, here is the debug output:

DEBUG: CmdletProcessRecordStart:
DEBUG: CmdletProcessRecordAsyncStart:
DEBUG: CmdletGetPipeline:
DEBUG: CmdletBeforeAPICall:
DEBUG: URLCreated: https://graph.microsoft.com/beta/security/alerts?$filter=Title eq 'Activity from infrequent country'
DEBUG: RequestCreated: https://graph.microsoft.com/beta/security/alerts?$filter=Title eq 'Activity from infrequent
country'
DEBUG: HeaderParametersAdded: https://graph.microsoft.com/beta/security/alerts?$filter=Title eq 'Activity from
infrequent country'
HTTP: graph.microsoft.com

DEBUG: BeforeCall:
DEBUG: ResponseCreated:
DEBUG: BeforeResponseDispatch:
DEBUG: GET
https://graph.microsoft.com/beta/security/alerts?$filter=Title%20eq%20'Activity%20from%20infrequent%20country'
HTTP/1.1 206 Partial Content
Transfer-Encoding: chunked
Warning: 199 - "Microsoft/Microsoft Defender ATP/400/248"
Vary: Accept-Encoding
Strict-Transport-Security: max-age=31536000
request-id: 3a642255-c544-41d8-ba73-08d2e7d37dff
client-request-id: 3a642255-c544-41d8-ba73-08d2e7d37dff
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"East
US","Slice":"E","Ring":"5","ScaleUnit":"001","RoleInstance":"MN1PEPF00002F29"}}
OData-Version: 4.0
Cache-Control: no-cache
Date: Mon, 18 Oct 2021 23:24:21 GMT
Content-Encoding: gzip
Content-Type: application/json; odata.metadata=minimal; odata.streaming=true; IEEE754Compatible=false; charset=utf-8

DEBUG: Finally:
DEBUG: CmdletAfterAPICall:
DEBUG: CmdletProcessRecordAsyncEnd:
DEBUG: CmdletProcessRecordEnd:
DEBUG: CmdletEndProcessing:

[peombwa]

It appears that this is a service issue given the 206 partial content status code and the Warning: 199 - "Microsoft/Microsoft Defender ATP/400/248" response header. Here is what the API reference says about this:

If successful, this method returns a 200 OK response code and collection of alert objects in the response body. If a status code other than 2xx or 404 is returned from a provider or if a provider times out, the response will be a 206 Partial Content status code with the provider's response in a warning header. For more information, see Microsoft Graph Security API error responses.

Reference: https://docs.microsoft.com/en-us/graph/api/resources/security-error-codes?view=graph-rest-1.0#errors

The same behavior can also be reproduced through Invoke-MgGraphRequest.

Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/beta/security/alerts?`$filter=Title eq 'Activity from infrequent country'" -Debug

@darrelmiller, is this a known issue with the workload?

The encoded request URI (https://graph.microsoft.com/beta/security/alerts?$filter=Title%20eq%20'Activity%20from%20infrequent%20country') being sent to the service is correct and should return the expected results with a 200 status code. Could try pasting the encoded URL in the debug log to Graph Explorer to see if it yields the expected results. Also, could you verify that you've logged in to the same tenant and user in PowerShell SDK as you have in Graph Explorer - Get-MgContext | select TenantId.

[helloitsliam]

I just double checked and yes I am logged into the Graph Explorer and PowerShell using the same account and Tenant. I took the encoded URL and pasted that into Graph Explorer and get the "Partial Content - 206" message.

Thanks

[darrelmiller]

The 206 response is an expected behavior. The API is designed to fan out to different alert providers and the 206 response is specifically intended to say that the API executed successfully but not all alert providers were able to provide results.
PowerShell should treat this 206 as if it were a 200 and display the warning to the console.

[helloitsliam]

As a side note, it returns all results, and ignores the filter being passed.

[peombwa]

Got it! In this case, we will need to update AutoREST.PowerShell to handle all 2xx status codes as success and log relevant warning headers (if present) to the warning stream in PowerShell.

Will be fixed by Azure/autorest.powershell#853 and #910.

[peombwa]

Also affects #749.

[peombwa]

AutoREST.PowerShell v3 now supports success status code range. The fix will be available in v2 of the module. We just need to:

• set UseSuccessStatusCodeRange = true in DevX API.

[peombwa]

Fixed by #907. Will ship in v2 of the module.