microsoft graph filter assigned role - azure-active-directory

In Azure Active Directory I created an app, in the manifest file I've update the appRoles with the following value:
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"displayName": "Client manager",
"id": "bf77e391-0bbf-4e33-854b-a384a5ac0630",
"isEnabled": true,
"description": "Client manager can manage all client actions.",
"value": "ClientManager"
}]
I updated my user so that my assigned role is no longer Default Access but is Client manager
With Graph api I'm trying to retrieve this assigned role.
I tried this uri but for some reason it will not return my role(s).
https://graph.microsoft.com/beta/me/appRoleAssignments?$filter=resourceId eq 04dcaab1-7219-4689-8510-4672e957ac11$select=appRoleId
But the response is:
{
"error": {
"code": "BadRequest",
"message": "Invalid filter clause",
"innerError": {
"request-id": "ce3cb456-956b-41c5-84a2-cdcdfe1ac3c5",
"date": "2018-11-05T20:54:08"
}
}
}
I could create a workaround requesting all my roles, for all my applications but this is something I would like to avoid. This would end up with the following uri:
https://graph.microsoft.com/beta/me/appRoleAssignments?$select=resourceId,appRoleId
and results in this json, where I need to filter out my applicationid.
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#appRoleAssignments(resourceId,appRoleId)",
"value": [
{
"appRoleId": "00000000-0000-0000-0000-000000000000",
"resourceId": "667cc3aa-00b9-4526-bde5-b81312ed5afb"
},
{
"appRoleId": "00000000-0000-0000-0000-000000000000",
"resourceId": "64b92ac1-4a56-478c-8774-5c584fb200e5"
},
{
"appRoleId": "bf77e391-0bbf-4e33-854b-a384a5ac0630",
"resourceId": "04dcaab1-7219-4689-8510-4672e957ac11"
}
]
}
I tried several solutions proposed on StackOverflow already but for some reason, all the eq filters don't work. I'm testing my query with the Graph explorer. My desired result should be something like this:
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#appRoleAssignments(appRoleId)",
"value": [
{
"appRoleId": "bf77e391-0bbf-4e33-854b-a384a5ac0630"
}
]
}

It seems not support to filter resourceId with https://graph.microsoft.com/beta/me/appRoleAssignments.
As mentioned in the doc:
Not all parameters are supported across all Microsoft Graph APIs, and support might differ significantly between the v1.0 and beta endpoints.
Also, if we filter the id with GET https://graph.microsoft.com/beta/me/appRoleAssignments?$filter=id eq 'xxxxxxx', it will work fine. So I think the format of the query should be correct, the only possibility is it is not supported as mentioned in the doc.

Related

Graph API User delta query not returning Manager following a change to the user

When I run this initial query:
https://graph.microsoft.com/beta/users/delta?$select=id,displayName,manager,jobTitle&$filter=id+eq+'87fa2ed7-5e58-4ff5-85ca-42a973e103e7'
I get the following response (as expected):
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#users(id,displayName,jobTitle,manager)",
"#odata.nextLink": "https://graph.microsoft.com/beta/users/delta?$skiptoken=<removed>",
"value": [
{
"displayName": "Jane Doe",
"jobTitle": "Super Administrator",
"id": "87fa2ed7-5e58-4ff5-85ca-42a973e103e7",
"manager#delta": [
{
"#odata.type": "#microsoft.graph.user",
"id": "1ab00b74-6f7e-45ca-8629-22d64632501d"
}
]
}
]
}
I follow the #odata.nextLink URL, which returns:
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#users",
"#odata.deltaLink": "https://graph.microsoft.com/beta/users/delta?$deltatoken=<removed>",
"value": []
}
I don't really understand why it doesn't just give me the deltaLink in the first call, but that isn't the issue. At this point, I make a change to the user's job title in Azure AD (outside of Graph API) and then follow the #odata.deltaLink, which returns:
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#users",
"#odata.deltaLink": "https://graph.microsoft.com/beta/users/delta?$deltatoken=<removed>",
"value": [
{
"displayName": "Jane Doe",
"jobTitle": "Administrator",
"id": "87fa2ed7-5e58-4ff5-85ca-42a973e103e7"
}
]
}
No manager!!
The only attribute changed was the job title; Manager is unchanged. This behavior is the same in both the v1.0 and beta endpoints. Also, I am not using the "prefer:return=minimal" header (or any additional headers for that matter).
Can anyone provide some insight into this?

Graph API: Schema Extension Date filter not working

I'm using a Schema Extension for Users. Filtering is not working for date values of this extension.
https://graph.microsoft.com/v1.0/users?$select=ext123455_UserExtension&$filter=ext123455_UserExtension/CreationDate ge '2020-02-08T09:59:20.8368277Z'
The response contains results where date CreationDate property is lower than 2020:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(ext123455_UserExtension)",
"value": [
{
"id": "23d17258-515c-4685-b95e-f98f2df8df56",
"ext123455_UserExtension": {
"#odata.type": "#microsoft.graph.ComplexExtensionValue",
"CreationDate": "2019-02-08T09:59:20.8354838Z",
}
}
]
}
The extension schema is:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#schemaExtensions/$entity",
"id": "ext123455_UserExtension",
"description": "Extension Test",
"targetTypes": [
"user"
],
"status": "InDevelopment",
"owner": "...",
"properties": [
{
"name": "CreationDate",
"type": "DateTime"
}
]
}
This could be connected to this question:
Filtering objects by date in MS Graph
P.S. This post has somehow disappeared from stackoverflow. I have therefore recreated it...
I'm afraid this won't work as AAD resources do not support ge.
From the documentation:
Note: The following $filter operators are not supported for Azure AD resources: ne, gt, ge, lt, le, and not. The contains string operator is currently not supported on any Microsoft Graph resources

create a application role using Microsoft Graph API

I have created app registration in azure aad. I want to add a app role using Microsoft Graph API programmatic.
It seems that there is no Microsoft Graph API to do that. If Azure AD graph is acceptable, you use the following rest API to do that.
PATCH https://graph.windows.net/{tenantId}/directoryObjects/{objectId}/Microsoft.DirectoryServices.Application?api-version=1.6
Note: objectId not applicationId, we could get it from Azure portal.
The following is the test body
appRoles": [
{
"allowedMemberTypes": [
"User"
],
"displayName": "SurveyAdmin",
"id": "c20e145e-5459-4a6c-a074-b942bbd4cfe1",
"isEnabled": true,
"description": "Administrators can manage the Surveys in their tenant",
"value": "SurveyAdmin"
}
]
Test result:
We also could check it in the application manifest from Azure portal.
According to my experience, I added appRoles with the help of MicrosoftGraphAPI. You can use this:
respond = "https://graph.microsoft.com/v1.0/applications/{apps-Object-ID}"
request_body = json.dumps({
"appRoles": [ {
"allowedMemberTypes": ['User'],
'description': 'access',
'displayName': 'access',
'id': "XXXX-XXXX-XXX",
"isEnabled": "true",
"value": "null",
"origin": "Application"
}
]
})
response = requests.patch(respond, headers, request_body)
And don't forget to import json and requests

Azure AD User Provisioning with SCIM 2.0

I'm trying SCIM 2.0 provisioning with Azure AD
As premise, I have SCIM a server for my product and I'm implementing PATCH endpoints for use with Okta and Microsoft Azure AD.
I'm done testing with Okta, so I'm trying with Azure AD now.
I read this post active-directory-scim-provisioning and the SCIM 2.0 Specification Section 3.5.2.
I set up an enterprise application on our Azure AD with the following mapping
Then, Azure AD sends the following JSON POST request to create users assigned to the application to my server:
POST:
{
"active": true,
"displayName": "$DISPLAY_NAME",
"emails": [
{
"primary": true,
"type": "work",
"value": "$EMAIL"
}
],
"externalId": "$EXTERNAL_ID",
"meta": {
"resourceType": "User"
},
"name": {
"formatted": "$FORMATTED"
},
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
],
"userName": "$USER_NAME"
}
I can process the POST request correctly, but I am unable to consume the PATCH request from Azure AD.
PATCH:
{
"Operations": [
{
"op": "Replace",
"path": "name.givenName",
"value": [
{
"$ref": null,
"value": "$VALUE"
}
]
},
{
"op": "Replace",
"path": "name.familyName",
"value": [
{
"$ref": null,
"value": "$VALUE"
}
]
}
],
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
]
}
Is it correct (according to the specification) that the value attribute is of type Array, even if the target is a single-valued attribute? Is the use of the $ref attribute correct in this case?
Or did I misunderstand the specification?
They have fixed it Dec 18 2018 :)
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/application-provisioning-config-problem-scim-compatibility
They made a mistake on the value implementation for non-complex objects. You can read more about it here https://social.msdn.microsoft.com/Forums/lync/en-US/e2200b69-4333-41ea-9f51-717d316c7751/automatic-user-provisioning-scim-restful-patch-payload-issue?forum=WindowsAzureAD

500 Error when trying to create schema extensions

I am trying to create schema extensions. I do have
"scp": "Directory.AccessAsUser.All" in token. Don't know for what reason it is failing.
https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/schemaextension_post_schemaextensions
POST https://graph.microsoft.com/beta/schemaExtensions
Content-type: application/json
{
"id":"courses",
"description": "Graph Learn training courses extensions",
"targetTypes": [
"Group"
],
"properties": [
{
"name": "courseId",
"type": "Integer"
},
{
"name": "courseName",
"type": "String"
},
{
"name": "courseType",
"type": "String"
}
]
}
error :
{
"error": {
"code": "Service_InternalServerError",
"message": "Encountered an internal server error.",
"innerError": {
"request-id": "1909aef3-b66d-48de-8204-0a41df0a27a8",
"date": "2017-07-17T13:07:20"
}
}
}
Unfortunately it looks like Microsoft Graph schema extensions is not supported in B2C tenant (please confirm if you are NOT using a B2C tenant - in which case this might be a different problem).
In the meantime (until we fix this issue), you'll need to use Azure AD Graph to register and use directory extensions.
Hope this helps,

Resources