SCIM Calls to Snowflake Error code 390404

Question

Hi,

I'm using Azure AD Automatic provisioning for a Snowflake Enterprise Application. Azure AD makes SCIM REST calls to Snowflake and, on the Snowflake side, it is recorded as SCIM event history in rest_event_history table. I've been noticing quite a few SCIM calls show a status of "NOT_FOUND" with error code 390404 when Azure makes a scim/v2/Users GET call. The details column shows "Invalid queryParam userName eq "06bd0ff2-6e64-3485-bede-152a70e69ae0"".

The user creation and updates seem to be working well but when there are SCIM errors, it is difficult to debug because all these GET calls that return an error makes it difficult and sometimes impossible to get to other errors that maybe relevant to the provisioning errors (Snowflake only returns the top 100 SCIM history records).

Can someone please explain what these GET call errors are and how they can be fixed?

Thanks,

Arun

Answer 1

At the start of a provisioning cycle, or when the Validate/Test Credentials button is clicked in the AAD Provisioning UI, some test actions are performed. One of those is checking authorization to query the SCIM server while also checking conformance with the SCIM specification. This is done via a GET /Users?filter=userName eq "String+randomguid". It sounds like Snowflake might be treating these as errors at least as far as its logging goes, which is questionable if so.

The expected response to the above example would be a 200/OK response with a SCIM-compliant response that says totalResults = 0. Either due to the GUID or just the lack of any users being found, it's being considered an error. If they are returning a 200/OK but log it as an error, it's mostly just noise. If they're responding to the GET with a 400 series error due to something about the value being queried - the string+guid piece - then that's probably not SCIM compliant.

It isn't clear, but if things are working and you're investigating here solely based on the logging provided on the Snowflake side, I'd suggest instead leveraging the AAD Provisioning logs instead.