I have a CosmosDB in Azure, I want to give a user access to read the data inside various collections.
I tried giving them the 'Reader'-role, it let them se that there existed a CosmosDB, and they could see some meta data. But they were unable to access the data within
I assigned them the 'Cosmos DB Account Reader' and this had better results.
But it seems to me that the 'Reader' role should superseed the 'Cosmos DB Account Reader' role. Or am i on the wrong track here? I beleived that the 'Reader'-role gave *all read access.
EDIT:
There seems to be no issue using the built in 'Data Explorer' on portal.azure.com.
The real issue is on using cosmos.azure.com, and logging inn using ActiveDirectory, did not let the user see anything with the 'Cosmos DB Account Reader'-role. Might be it requires a user has write-access.
In order to read the data from Cosmos DB accounts, a user should be in a role that allows fetching access keys. A Reader role does not have this capability. However
Cosmos DB Account Reader role has the capability to fetch the read-only access keys using which a user in this role can read the data (but not make any changes to that data).
From this link, here's the definition of Cosmos DB Account Reader role:
{
"assignableScopes": [
"/"
],
"description": "Can read Azure Cosmos DB Accounts data",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/fbdf93bf-df7d-467e-a4d2-9458aa1360c8",
"name": "fbdf93bf-df7d-467e-a4d2-9458aa1360c8",
"permissions": [
{
"actions": [
"Microsoft.Authorization/*/read",
"Microsoft.DocumentDB/*/read",
"Microsoft.DocumentDB/databaseAccounts/readonlykeys/action",
"Microsoft.Insights/MetricDefinitions/read",
"Microsoft.Insights/Metrics/read",
"Microsoft.Resources/subscriptions/resourceGroups/read",
"Microsoft.Support/*"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"roleName": "Cosmos DB Account Reader Role",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
Microsoft.DocumentDB/databaseAccounts/readonlykeys/action action enables getting read-only access keys and thus read the data.
Related
I am trying to setup narrow down the best possible role for monitoring data from security perspective. My needs are slightly different so I don't want to use the Security Reader role (mainly because security reader only has access to the security center items and basic resource and resource group queries). So after reading more I stumbled upon Monitoring Reader role and just Reader role. I went through the permissions mentioned in the JSON. However I am not sure if all the differences are covered in the JSON.
For instance when we talk about "Monitoring Reader"
{
"assignableScopes": [
"/"
],
"description": "Can read all monitoring data.",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/43d0d8ad-25c7-4714-9337-8ba259a9fe05",
"name": "43d0d8ad-25c7-4714-9337-8ba259a9fe05",
"permissions": [
{
"actions": [
"*/read",
"Microsoft.OperationalInsights/workspaces/search/action",
"Microsoft.Support/*"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"roleName": "Monitoring Reader",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
The privileges are basically the same expect that I can query the logs. Compared to the Reader role which is
{
"assignableScopes": [
"/"
],
"description": "Lets you view everything, but not make any changes.",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7",
"name": "acdd72a7-3385-48ef-bd42-f606fba81ae7",
"permissions": [
{
"actions": [
"*/read"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"roleName": "Reader",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
Now from a logical standpoint if both the users are able to execute */read doesn't Reader role automatically qualify to query the logs? If not, how is it different? Also which role is superior in terms of access to readable data?
Reference : https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#reader
PS : I do know about custom roles but want to understand built-in roles better.
Now from a logical standpoint if both the users are able to execute */read doesn't Reader role automatically qualify to query the logs?
They are both able to execute */read, but Reader cannot query the logs.
If not, how is it different?
The difference is Monitoring Reader can execute the Microsoft.OperationalInsights/workspaces/search/action and Microsoft.Support/* actions.
Also which role is superior in terms of access to readable data?
From the actions scope of the role definition, obviously the Monitoring Reader is superior in terms of access to readable data.
I'm designing a solution for an ERP requirement. The Client insists on using AAD for one point management of users for different applications.
Since AAD has the capability of rendering Oauth service, I'm intending to use it as my OAUTH server and utilize its tokens inside my WebAPI services. But was wondering how I can capture the failed user login attempts as I need to apply locking mechanism.
When I found that AAD can handle this locking mechanism also through some configurations, I'm now left out with a question whether I can just use AAD for my user store, meaning I will have the users, their credentials and their roles stored in AAD, while I will have the permissions for each role and other data stored in my application's database.
Is this a feasible solution? or is there a different way of handling this?
Note: We are using noSQL database.
Yes, this is a feasible solution. You can use application roles to assign roles to users.
You can define the application roles by adding them to the application manifest. Then you can assign these roles to a user.
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"description": "Creators can create Surveys",
"displayName": "SurveyCreator",
"id": "1b4f816e-5eaf-48b9-8613-7923830595ad",
"isEnabled": true,
"value": "SurveyCreator"
},
{
"allowedMemberTypes": [
"User"
],
"description": "Administrators can manage the Surveys in their tenant",
"displayName": "SurveyAdmin",
"id": "c20e145e-5459-4a6c-a074-b942bbd4cfe1",
"isEnabled": true,
"value": "SurveyAdmin"
}
],
The user list with roles listed.
I have a requirement, where I needed to fetch the tenantDirectoryId for a given subscription.
I could find a rest get api https://management.azure.com/subscriptions/[subscription]/versions...
The error response to this gave the tenant directory.
Is there any better way to fetch directory for a subscriptionId.
As of now (06/07/2018), an easy approach would be running az account show in the Azure Cloud Shell (requires a Storage Account) in the Azure Portal.
--- Command ---
az account show
--- Command Output ---
{
"environmentName": "AzureCloud",
"id": "{Subscription Id (GUID)}",
"isDefault": true,
"name": "{Subscription Name}",
"state": "Enabled",
"tenantId": "{Tenant Id (GUID)}",
"user": {
"cloudShellID": true,
"name": "{User email}",
"type": "user"
}
}
See this doc for more details on Azure Cloud Shell: https://learn.microsoft.com/en-us/azure/cloud-shell/overview
We have recently had the same problem we wanted to fix. After speaking to Microsoft there is no supported way to do this through the Graph API when accessing as an application using the client_credentialflow.
An approach we have taken to get the tenant id is to call the OAuth2 metadata document endpoint for your tenant
https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration
By calling this you’ll see your token endpoint as well as other useful information listed which you can utilise to log in. Or you can grab the tenant id using string stripping.
I created admin console in the User interface where admin can perform all the operations such create, delete the user, assign applications to user and remove application access to users from the user interface
I tired to remove application access to the users from the User Interface by using Microsoft graph API and Azure AD graph api
i used following azure AD graph api
https://graph.windows.net/tenantid/users/{userId}/appRoleAssignments/{appId}?api-version=1.6
but it is showing the error when i tested in the postman "Invalid resource identifier for EntitlementGrant."
Idont know what to do can anyone help me about these error and how to resolve these problem.
You may be getting this error because you are trying to delete the application access using AppId of the application. Please make sure to use "AssignmentID" from Azure Portal which is unique ID of the specific role assignment and links the user/group and the service principal object.
Go to Azure Active Directory > Users > Select specific User > Applications > Select any application to navigate to "Assignment Details" blade.
See screenshot below -
This unique id is also available as "ObjectID" if querying application role assignments through Graph API -
https://graph.windows.net/{TenantID}/users/{UserID}/appRoleAssignments
Here is the sample output of the above API call.
"odata.metadata": "https://graph.windows.net/sasharms.onmicrosoft.com/$metadata#directoryObjects/Microsoft.DirectoryServices.AppRoleAssignment",
"value": [
{
"odata.type": "Microsoft.DirectoryServices.AppRoleAssignment",
"objectType": "AppRoleAssignment",
"objectId": "r7rDMrnDo0uCuwnosRwwzuziiF5B8s9FnsotYya5DMU",
"deletionTimestamp": null,
"creationTimestamp": "2018-05-10T14:10:49.8197813Z",
"id": "00000000-0000-0000-0000-000000000000",
"principalDisplayName": "SaurabhSharma",
"principalId": "32c3baaf-c3b9-4ba3-82bb-09e8b11c30ce",
"principalType": "User",
"resourceDisplayName": "WebAppOpenIdGraphApi",
"resourceId": "90658e39-2559-48fb-a27a-5e50cca94288"
}
This Id is ideally used for performing various operations against the application using any programmatic interfaces like PowerShell and Graph APIs.
I am trying to add required permissions to an Azure AD application. I already know how to replicate information from a downloaded manifest through a PATCH REST call, e.g.
"requiredResourceAccess": [
{
"resourceAppId": "00000003-0000-0000-c000-000000000000",
"resourceAccess": [
{
"id": "7b9103a5-4610-446b-9670-80643382c1fa",
"type": "Scope"
},
{
"id": "5df07973-7d5d-46ed-9847-1271055cbd51",
"type": "Scope"
}
]
}
]
As explained by Christer Ljung on his blog http://www.redbaronofazure.com/?page_id=181.
But the mystery remains how I can "convert" human-readable scopes such as Mail.Read to these obscure guids. I have read the following blog of Sahil Malik's at http://blah.winsmarts.com/2015-1-Programmatically_register_native_apps_in_Azure_AD_or_Office_365.aspx that explains how to get a list of available guids for a particular ServicePrincipal. E.g. through an http get to https://graph.windows.net/<tenant-id>/servicePrincipals()?api-version=1.6&$filter=appId%20eq%20'00000002-0000-0ff1-ce00-000000000000'> (Exchange) but when I try to get the list of available scopes of ServicePrincipal 00000003-0000-0000-c000-000000000000 (I believe the one for Graph API) the return value is just empty.
Interestingly, with Fiddler I was able to capture an http post request which contains all the guids when adding the permissions through Azure Portal.
Anyone any clue how I can do this programmatically?
After investigation, I discover a way to get permission guid using azure-cli. Share here in case anyone is finding this:
get all permisson and their GUID of a certain service principal by display-name, app-id or object-id. (Note that display-name is not unique and can maps multiple service principal)
$ az ad sp list --filter "displayName eq 'Microsoft Graph'" --query '[].oauth2Permissions[].{Value:value, Id:id, UserConsentDisplayName:userConsentDisplayName}' -o table
Value Id UserConsentDisplayName
------------------------------------------------------- ------------------------------------ -----------------------------------------------------------------------------------------
ServiceHealth.Read.All 55896846-df78-47a7-aa94-8d3d4442ca7f Read service health
ServiceMessage.Read.All eda39fa6-f8cf-4c3c-a909-432c683e4c9b Read service messages
TermStore.ReadWrite.All 6c37c71d-f50f-4bff-8fd3-8a41da390140 Read and write term store data
TermStore.Read.All 297f747b-0005-475b-8fef-c890f5152b38 Read term store data
TeamMember.ReadWriteNonOwnerRole.All 2104a4db-3a2f-4ea0-9dba-143d457dc666 Add and remove members with non-owner role for all teams
Team.Create 7825d5d6-6049-4ce7-bdf6-3b8d53f4bcd0 Create teams
TeamsAppInstallation.ReadWriteForUser 093f8818-d05f-49b8-95bc-9d2a73e9a43c Manage your installed Teams apps
TeamsAppInstallation.ReadWriteSelfForUser 207e0cb1-3ce7-4922-b991-5a760c346ebc Allow the Teams app to manage itself for you
...
$ az ad sp list --filter "appId eq '00000003-0000-0000-c000-000000000000'" --query '[].oauth2Permissions[].{Value:value, Id:id, UserConsentDisplayName:userConsentDisplayName}' -o table | head
Value Id UserConsentDisplayName
------------------------------------------------------- ------------------------------------ -----------------------------------------------------------------------------------------
ServiceHealth.Read.All 55896846-df78-47a7-aa94-8d3d4442ca7f Read service health
ServiceMessage.Read.All eda39fa6-f8cf-4c3c-a909-432c683e4c9b Read service messages
TermStore.ReadWrite.All 6c37c71d-f50f-4bff-8fd3-8a41da390140 Read and write term store data
TermStore.Read.All 297f747b-0005-475b-8fef-c890f5152b38 Read term store data
TeamMember.ReadWriteNonOwnerRole.All 2104a4db-3a2f-4ea0-9dba-143d457dc666 Add and remove members with non-owner role for all teams
Team.Create 7825d5d6-6049-4ce7-bdf6-3b8d53f4bcd0 Create teams
TeamsAppInstallation.ReadWriteForUser 093f8818-d05f-49b8-95bc-9d2a73e9a43c Manage your installed Teams apps
TeamsAppInstallation.ReadWriteSelfForUser 207e0cb1-3ce7-4922-b991-5a760c346ebc Allow the Teams app to manage itself for you
...
Run the below command to get full information of certain service principal including its oauth2Permissions and servicePrincipalNames, etc.
az ad sp show --id 00000003-0000-0000-c000-000000000000 >microsoft_graph_permission_list.json
# microsoft_graph_permission_list.json
{
...
"appDisplayName": "Microsoft Graph",
"appId": "00000003-0000-0000-c000-000000000000",
"objectId": "b19d498e-6687-4156-869a-2e8a95a9d659",
"servicePrincipalNames": [
"https://dod-graph.microsoft.us",
"https://graph.microsoft.com/",
"https://graph.microsoft.us",
"00000003-0000-0000-c000-000000000000/ags.windows.net",
"00000003-0000-0000-c000-000000000000",
"https://canary.graph.microsoft.com",
"https://graph.microsoft.com",
"https://ags.windows.net"
],
"appRoles": [...],
"oauth2Permissions": [
{
"adminConsentDescription": "Allows the app to read and write the full set of profile properties, reports, and managers of other users in your organization, on behalf of the signed-in user.",
"adminConsentDisplayName": "Read and write all users' full profiles",
"id": "204e0828-b5ca-4ad8-b9f3-f32a958e7cc4",
"isEnabled": true,
"type": "Admin",
"userConsentDescription": "Allows the app to read and write the full set of profile properties, reports, and managers of other users in your organization, on your behalf.",
"userConsentDisplayName": "Read and write all users' full profiles",
"value": "User.ReadWrite.All"
},
{
"adminConsentDescription": "Allows the app to read the full set of profile properties, reports, and managers of other users in your organization, on behalf of the signed-in user.",
"adminConsentDisplayName": "Read all users' full profiles",
"id": "a154be20-db9c-4678-8ab7-66f6cc099a59",
"isEnabled": true,
"type": "Admin",
"userConsentDescription": "Allows the app to read the full set of profile properties, reports, and managers of other users in your organization, on your behalf.",
"userConsentDisplayName": "Read all users' full profiles",
"value": "User.Read.All"
},
...
]
...
}
Few things to say about this topic.
First, it is important to note that all of the OAuth2Permission Scopes are registered on the main Application Object in the developer's tenant. Thus, in general, you would not have access to that information, since it would be in a tenant where you are not a user. So as an external developer, these permission scopes are not discoverable via our APIs.
Second, you are able to see that the Azure Portal has access to this information because it has elevated access to query the OAuth2Permissions for all resources in all tenants. This is how our UX is able to populate all the permissions for all the various external and internal resources that you want to use in your tenant. The portal will first check which service principals are in your tenant (service principals get provisioned most commonly once you consent to use the application), then it will look up the Application Object that corresponds to that service principal, and find all the permission scopes. This behavior will hopefully allow you to only see the resource applications which are relevant to you, rather than populating your screen with all possible resources.
Finally, moving forward we are looking to take a step back from having to statically register permissions that clients require to call resource applications. Instead we will be pushing a new Incremental and Dynamic Consent framework. You will note that here that we are taking a dependency on the scope names, rather than the ObjectID GUIDs of those permissions as we did in the past. But still, I agree with you in general that the discoverability of the scopes that resources expose is very heavily dependent their own public documentation. I imagine in the future there might be an endpoint which exposes all the scopes available on a particular resource, but I know of no such work to do this in the near future.
Let me know if this helps!