Azure Logic app, AzureAD remove group members, insuficcient permission - permissions

I'm creating a Azure Logic app to replace members of defined Azure AD group. I have used this blog (https://geekshangout.com/logic-app-remove-azure-ad-group-members/) as of base for my job, but so far remove-member fails with insufficient permissions.
Basically logic app does:
Retrieve list of users from Azure SQL table with specific query: OK
Get list of users from AzureAD group : OK
For-each member:
remove member.objectID from azure group object ID:: Fails with following error:
"body": {
"error": {
"code": "Authorization_RequestDenied",
"message": "Insufficient privileges to complete the operation.",
"innerError": {
"date": "2022-02-10T07:32:44",
"request-id": "--------------",
"client-request-id": "------------"
}
}
}
So far: I re-created the logic app and taking care of:
Admin consent is given as described in the blog, by using the Global Admin account.
I can see in the 'Enterprise Applications' blade this 'logic app' created
permissions should be correct: API name: Microsoft graph, Claims: Directory.readwrite.all, group.readwrite.all, user.readwrite.all, offline_access , as of Microsoft documentation describes (https://learn.microsoft.com/en-us/connectors/azuread/)
Awaited now about 24 hours, so no 'cloud-lag' should be problem.
Should this 'Enterprise Application' have an additional permissions? If so, what and where?
Already tried to create a custom role with permissions described here: https://learn.microsoft.com/en-us/azure/active-directory/roles/custom-group-permissions
"Life is not a problem to be solved, but a reality to be experienced"
~T

Assuming the user with which you set up the Logic Apps connection for Azure AD is authorized to manage this group's membership (e.g. which would be the case if this was a Global Administrator), the most likely cause for this is that the group you are trying to change membership for is a role-assignable group.
Role-assignable groups are special groups to which directory roles can be assigned. Adding a member to the group is equivalent to assigning a directory role to that member, so neither of the delegated permissions Directory.ReadWrite.All nor Group.ReadWrite.All allow this. (For regular groups, either of them would be sufficient.) The app would also need to be granted the delegated permission RoleManagement.ReadWrite.Directory.
From the look of things, the built-in Logic Apps connector for Azure AD is not built to handle group membership for role-assignable groups.
If you really do need to be able to do this, you could update the delegated permissions granted to the connector to include RoleManagement.ReadWrite.Directory, but you should be very careful about this (and your entire solution, including the SQL database and the Logic App), as misuse could carry significant security risks.

Related

Azure Data Factory - share Integration Runtime on different Resource Groups

In an Azure Data Factory (ADF_1) from a Resource Group (RS_1), I need to share a self-hosted IntegrationRuntime from ADF_1 (where this IntegrationRuntime resides and run well) into ADF_2, located in another Resource Group (RS_2).
For sharing process the first step is:
"1.Grant permission to the Data Factory in which you would like to reference this IR (shared)"
When I'm trying to grant permission from UI, I receive the error:
"The client 'xxx#yyy.com' with object id 'xxxx' does not have authorization to perform action 'Microsoft.Authorization/roleAssignments/write' over scope '/subscriptions/...' or the scope is invalid."
My role is 'Contributor' on both Resource Groups (RS_1 & RS_2)
Thanks a lot for any suggestion
The Contributor role is not enough to add the role assignments(i.e. grant permission in this case), to do this, you need the Microsoft.Authorization/roleAssignments/write action permission as mentioned in the error message.
To solve the issue, your account needs the role which has Microsoft.Authorization/roleAssignments/write permission e.g. User Access Administrator or Owner.

Graph api GET group/planner/plan fails because of permission. This flow used to work lately. Any change happenned on this?

I have a Flow that retrieves a Token then uses it to perform Graph calls to groups API with the HTTP Premium connector.
I have a successful call to :
https://graph.microsoft.com/v1.0/groups/859[...]/owners
This shows my token is valid and has the permissions needed for this call.
Then I have a failing call to :
https://graph.microsoft.com/v1.0/groups/859[...]/planner/plans
You do not have the required permissions to access this item.
According to MS doc, the permission needed are :
/owners : Delegated (work or school account) Group.Read.All and
User.ReadBasic.All, Group.Read.All and User.Read.All, Group.Read.All
and User.ReadWrite.All, Group.Read.All and User.Read.All and
Application.Read.All
/plans : Delegated (work or school account) Group.Read.All,
Group.ReadWrite.All
Here is the permissions from the token I retrieve in my Flow :
"scope": "ChannelMember.ReadWrite.All Group.ReadWrite.All
GroupMember.ReadWrite.All User.Read User.Read.All"
All of those permission has been granted in the Sharepoint admin console.
Any idea of what is going wrong here ?
The likely issue is that you are an owner of the group, but not a member (these are two separate collections of people). Currently Planner data for a Group can only be accessed by members. If you are an owner, you can also add yourself as a member to gain access.

Vault OIDC with google, how to restrict roles to specific groups

I installed a vault and configured OIDC with gsuite, that was already an adventure in itself as the documentation is limited and even wrong at more than one place.
Finally I have a working authentication with my google accounts and I began to create roles, and there I saw a huge issue. How do you restrict google users from using a role. Let's say I create a gsuite-admin role that has access to all of vault administration, any user entering the role before login can assume it.
I tried to use the different claims but those seems to be only for vault created groups or other things.
Does anyone has a solution for that?
Thank you in advance.
EDIT:
The configuration I'm using whith group claims:
{
“allowed_redirect_uris”: “https://URL/ui/vault/auth/oidc/oidc/callback,http://localhost:8250/oidc/callback”,
“user_claim”: “sub”,
“policies”: “vault_admin”,
“ttl”: “24h”,
“groups_claim”: “devops”,
“oidc_scopes”: “profile”,
“bound_claims”: {
“group”: [“devops”]
}
}
That configuration only provides a lock of the role that can't be used anymore by anyone. From what I could see the JWT doesn't have any informations and that is why we used the config with the fetchgroup option in the oidc configuration.
I found a solution for this problem. Firstly, we need to ensure that a user is part of a G Suite group. Then mapping the G Suite group with Vault group (that has a policy assigned) ensures that the user is bound to the Vault policy.
This article contains some example steps and might be helpful.

Azure AD and Authorization on self Developed Applications

I have read the documentation on Microsoft.com and have only got answers about giving Applications authorization to talk to eachother but not how to implement a permission system on each different application that I have.
I basically want to know what the best practices are to implement Authorization on my .Net API and Angular Client.
I would use Azure AD to redirect external and internal users to the Microsoft Sign-In Page, I am missing a fine grained Permission system to authorise users to access different Resources on the API or on the Angular Web Application.
Wo I have to set up a DB for my API with permissions?
How do I add new users to my DB after registering them to my AD?
Im really confused here, so my questions aren´t really as clear as I wish I could write them.
Compiling comments to a proper answer:
Per-user permissions are limited to appRoles, roles that you can give in Azure AD to users. You can also use security groups to achieve a similar thing if you want. But anything finer-grained has to be implemented on the app side.
For identifying users you can use one of two claims in the user Id token / access token. oid or sub. The oid is the unique immutable object id in Azure AD. The sub claim is a unique immutable id within your app. So every app gets the same oid, but a different sub for the same user. The oid claim is also used when calling e.g. MS Graph API to identify the user.

Resource based authorization with Azure AD?

Here is the scenario, I have a service containing many records. My service also has many users, each with the ability to create, read, update and delete records. The ability to perform these operations on each record must be controlled at the record level.
For example, user A can only read and update record 1 but user B can read, update and delete records 1, 2 and 3 and user C can perform all operations on all records.
How if at all, can this be done using Azure AD?
Obviously, using application roles is not sufficient because that gives the user uniform access rights to all records.
The tenant is also not useful because its the same for all users (in this example).
I definitely do not want to define access rights for every record individually, I would like to do something like assigning roles to a user group and then somehow assign records to the group.
Is there a standard way to deal with this type of resource based authorization?
As you correctly mention, role based access or authorization is very generic and using that, a user with specific role gets access (or gets denied access) to all resources. (If your sceanrio permits, you could make it a little better by dividing your resources into a few types and give access for 1 or more types of resources to 1 or more roles).
When trying to control access for each record individually, you will need to implement custom logic for resource based authorization. Typically applications utilize a mix of role-based and resource-based authorization driven by their requirements.
In the end it will boil down to a mapping that you need to maintain between 3 things
Resource (or a collection of resources)
Azure AD object (like role, group, individual user that is being given permission)
Permission that you're giving (understood and enforced by your application e.g. Blogs.Create permission for a Blogs application)
Relevant Documentation available on Microsoft Docs
Role-based and resource-based authorization
This documentation talks about similar concepts and shows a good example which makes use of both role based and resource based. CRUD operations on resources based on roles and then special privileges on specific resource for the owner of that resource (i.e. resource based)
Code Samples
Multi-tenant Survey Application Code
Code base for the documentation link above
Authorization in a web app using Azure AD groups & group claims
This one provides a sample task tracker application where users can share tasks with other users or Azure AD groups. Again you will see a mapping between resources (i.e. tasks in this case) and Azure AD objects (i.e. Users or Groups) is being maintained in sample database.
Assigning Application Roles for groups
Since you mentioned this as part of your question, just letting you know that this is possible from Azure Portal but only if you have Azure AD Premium license (I'm not sure which specific ones support it, but search on Group based assignments feature and you'll find it.)