I have few users with 'Application Administrator' role. I don't want those users to manage all applications.
So, I tried to implement conditional access policy to block access. I came to know I can select users with directory roles while creating policy.
In Portal, I'm able to create policy and configure it with no loss. But I want to know if the same is possible using Graph Api or not.
Anyone achieved this from Graph? Please help me with whole steps to follow.
TIA
I tried to reproduce the same in my environment via Graph Explorer and got the below results:
You can make use of below graph query to create conditional access policy:
POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies
Content-type: application/json
{
"displayName": "Block access to Application Admins.",
"state": "enabled",
"conditions": {
"clientAppTypes": [
"all"
],
"applications": {
"includeApplications": [
"appID1",
"appID2"
]
},
"users": {
"includeRoles": [
"9b895d92-2cd3-44c7-9d02-a6ac2d5ea5c3"//ID of Application Admin role
]
}
},
"grantControls": {
"operator": "OR",
"builtInControls": [
"block"
]
}
}
Response:
To confirm that, I checked in Azure Portal where policy is created successfully like below:
When I opened that policy, the users with Application Administrator role are selected as below:
Related
I have user and group provisioning set up for an enterprise application in Azure AD. I have a SCIM endpoint setup in my application to consume the SCIM requests from Azure AD. I added this feature flag to my tenant URL to ensure SCIM compliance: https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/application-provisioning-config-problem-scim-compatibility#flags-to-alter-the-scim-behavior
I have a group assigned to the enterprise application for provisioning to my application. When I add users to that group in Azure AD, I'm seeing two PATCH requests to the Groups/:id SCIM endpoint. The first is an add operation, which I expect because I'm adding this user as a member of the group:
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "add",
"path": "members",
"value": [
{
"value": "directory_user_01F7SGPZHKVGHZMCRNHGJXW1E9"
}
]
}
]
}
The second PATCH request is a replace operation, which is unexpected as I'm not replacing all users in a group with the one member being added:
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "replace",
"path": "members",
"value": [
{
"value": "directory_user_01F7SGPZHKVGHZMCRNHGJXW1E9"
}
]
}
]
}
The SCIM protocol RFC outlines the difference between the add and replace operations in PATCH requests. If users are added as members of a group, there should only be an add operation, not a replace operation. Is there any way to configure Azure so it only sends add operations in this situation? Thanks!
Using Azure AD Premium, Enterprise App & SCIM 2.0 Provisioning Scope - Only assigned Users & Groups
I'm trying to work through the use case below:
SCIM provisioning of users that are assigned to a given AD Group
When a user is added (provisioned) to a group it correctly fires off a PATCH /Groups/{Id} to add member of the group
When a user is removed (deprovisioned) from the group it does not correctly fires a PATCH /Groups/{Id} to remove member of the group
What am I'm doing wrong?
In addition, I wonder which call azure active directory executes to get to know who is currently member of a given group. (I've noticed that every call AAD makes to my SCIM/group service implementation has the excludedAttributes=members as query parameter)
Any suggestions appreciated.
From what I saw, Azure SCIM sends this request to groups endpoint:
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "Remove",
"path": "members",
"value": [
{
"value": "49a5f81e-9f63-4f5e-b3e8-41db044c1af9"
}
]
}
]
}
I use ngrok during the development to see an analyse requests from Azure SCIM integration.
I'm trying to call above API provider via REST with the following URL:
https://management.azure.com/providers/microsoft.aadiam/diagnosticSettings with api-version=2017-04-01-preview
However, even though the Service Principal I am using is a member of the "Global Administrator" role in my AAD tenant I am getting a does not have authorization to perform action error.
This endpoint doesn't seem to be documented though.
Anybody know what is required to call this API endpoint with a service principal?
Thanks,
David
Try to add a custom role with the action of microsoft.aadiam/diagnosticsettings/write in your AD App.
According to doc, you can use the custom role to do the operation.
This article lists the operations available for each Azure Resource Manager resource provider. These operations can be used in custom roles to provide granular role-based access control (RBAC) to resources in Azure.
For more details to create the custom role, refer to this link.
Sample:
{
"Name": "Test Operator",
"Id": "88888888-8888-8888-8888-888888888888",
"IsCustom": true,
"Description": "xxxxxx",
"Actions": [
microsoft.aadiam/diagnosticsettings/write,
microsoft.aadiam/diagnosticsettings/read
],
"NotActions": [
],
"DataActions": [
],
"NotDataActions": [
],
"AssignableScopes": [
"/subscriptions/{subscriptionId1}",
"/subscriptions/{subscriptionId2}",
"/subscriptions/{subscriptionId3}"
]
}
Update:
You can use a user account with global admin role, refer to the steps below.
1.Navigate to Azure Active Directory -> Diagnostic settings -> Add diagnostic setting -> set the properties and open the Developer Tools(F12) ->Save.
2.In the request we caught, copy the Bearer token.
3.Then we can test the api in the postman.
Request URL:
Put https://management.azure.com/providers/microsoft.aadiam/diagnosticSettings/{name}?api-version=2017-04-01-preview
Request Header:
Request Body:
{
"properties": {
"logs": [
{
"category": "AuditLogs",
"enabled": true,
"retentionPolicy": {
"days": 0,
"enabled": false
}
},
{
"category": "SignInLogs",
"enabled": true,
"retentionPolicy": {
"days": 0,
"enabled": false
}
}
],
"metrics": [],
"storageAccountId": "/subscriptions/xxxx/resourceGroups/xxx/providers/Microsoft.Storage/storageAccounts/xxx"
}
}
It works on my side.
I test it with global administrator user, it works correctly for me.
The following is the detail steps:
Create an native azure AD application and grant permission for it.
2.create an global administrator user, please also change the default password.
Note: the user format should be xxxx#xxx.onmicrosoft.com, or you can't use the password way to get the token based on my test
3.Assign the owner role to the subscription
4.Then we could use the following way to get the access token
Post https://login.windows.net/<tenant-id>/oauth2/token
Content-Type: application/x-www-form-urlencoded
grant_type=password
&resource={resource}
&username={username}
&password={password}
&client_id={client-id}
4.Try to operate the diagnosticSettings
put https://management.azure.com/providers/microsoft.aadiam/diagnosticSettings/{name}?api-version=2017-04-01-preview
{"properties":{"logs":[{"category":"AuditLogs","enabled":true,"retentionPolicy":{"days":0,"enabled":false}},{"category":"SignInLogs","enabled":false,"retentionPolicy":{"days":0,"enabled":false}}],"metrics":[],"storageAccountId":"/subscriptions/{subscriptionId}/resourceGroups/{groupname}/providers/Microsoft.Storage/storageAccounts/{accountName}"}}
i wanted to add an extended property in Azure Ad which will be accessible across groups in AD.Got this
POST https://graph.windows.net/contoso.com/applications//extensionProperties?api-version=1.21-preview { “name”: “skypeId”, “dataType”: “String”, “targetObjects”: [“User”] }
Wanted to understand 2 things which the document is not clear to me on:-
1.if the "targetObjects" is specified as user will the extended property appear across groups as well as users in an application
2.can this be done directly via azure portal without using the https://graphexplorer.cloudapp.net/ as mentioned in the document
https://msdn.microsoft.com/library/azure/ad/graph/howto/azure-ad-graph-api-directory-schema-extensions#RegisterAnExtension
Does anybody have an idea on this?
if the "targetObjects" is specified as user will the extended property
appear across groups as well as users in an application
You set the "targetObjects" as the user, that means this extended property will be added in the user's attributes and also can appear across groups as well as users in this application.
can this be done directly via the Azure portal
For now, you cannot do this via the Azure portal. You could do this by using Azure AD Graph API(you tried) or Microsoft Graph API, or you can also use AAD PowerShell.
If you persist in doing this via the portal, the B2C portal is suggested for you. You could manually define a custom attribute for the user. For the details, you could read this doc.
Using Microsoft Graph API:
POST https://graph.microsoft.com/v1.0/schemaExtensions
Content-type: application/json
{
"id":"graphlearn_courses",
"description": "Graph Learn training courses extensions",
"targetTypes": [
"Group"
],
"properties": [
{
"name": "courseId",
"type": "Integer"
},
{
"name": "courseName",
"type": "String"
},
{
"name": "courseType",
"type": "String"
}
]
}
For the details, you could read here.
Using AAD PowerShell:
Set-AzureADUserExtension
-ObjectId <String>
-ExtensionName <String>
-ExtensionValue <String>
[<CommonParameters>]
For the details, you could refer to here.
Using the extension API documented here:
https://msdn.microsoft.com/en-us/library/azure/ad/graph/howto/azure-ad-graph-api-directory-schema-extensions
in conjuction with the B2C Graph Client sample:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet
I created a custom attribute via the AD Graph API for directory schema extensions using this API:
POST
https://graph.windows.net/contoso.onmicrosoft.com/applications/<applicationObjectId>/extensionProperties?api-version=1.6
{
name: "OrgRoleId",
dataType: "String",
targetObjects: [
"User"
]
}
(Note I changed the API version to 1.6).
The API created custom attributes appear using the B2CGraphClient sample and has the same data as those registered via the Azure portal for B2C.
However, these API created custom attributes don't appear in the Azure portal 'User attributes' blade for the tenant, while those custom attributes created via the Azure portal for the B2C tenant do.
Note that I can successfully read and write these extension values for users (via the Graph API). I just cannot put them into claims because they don't appear on the 'User attributes' blade nor the policy claims blade in the Azure portal, and therefore they are not added as claims to the token.
What I am missing/doing wrong?
Output from B2C.exe Get-extension-attribute <b2c-extensions-app objectId>. *_Test1 appears (portal created), while *_UserRoleId does not (API created):
{
"odata.metadata": "https://graph.windows.net/<tenant_id>/$metadata#directoryObjects/Microsoft.DirectoryServices.ExtensionProperty",
"value": [
{
"odata.type": "Microsoft.DirectoryServices.ExtensionProperty",
"objectType": "ExtensionProperty",
"objectId": "f58bc813-632c-486b-bff1-61695eeab691",
"deletionTimestamp": null,
"appDisplayName": "",
"name": "extension_<object_id>_Test1",
"dataType": "String",
"isSyncedFromOnPremises": false,
"targetObjects": [
"User"
]
},
{
"odata.type": "Microsoft.DirectoryServices.ExtensionProperty",
"objectType": "ExtensionProperty",
"objectId": "5e69b2d9-1ab0-463f-a231-5c188e92b4a1",
"deletionTimestamp": null,
"appDisplayName": "",
"name": "extension_<object_id>_UserRoleId",
"dataType": "String",
"isSyncedFromOnPremises": false,
"targetObjects": [
"User"
]
}
...
When you add an extension attribute through the portal, it is created in the directory and owned by the b2c-extensions-app application and it is also added to a tenant-wide policy. That is what allows you to use them in application policies as you create them.
When you create an extension attribute using Graph API, it is not added to the policy and usually created on an application other than b2c-extensions-app. You can use these properties directly in custom policies, but they will not appear in the portal and cannot be used in the policies created through the portal.
It is a best practice to just create the extension properties through the portal so they are available for all policies. This allows customers to mix and match custom policies with built-in b2c user flows.