Using IAM, I am trying to allow certain users to access API's and allow them to create OAuth client credentials. Is there a predefined role for allowing this? I don't want to use the role of project editor, because I'm trying to allow access to only the necessary services.
It's when the user is in their project, and they go to "APIs and Services" > Credentials, the user receives this error:
You don't have permission to view API keys, OAuth clients, and service account keys.
Roles/Permissions:
-App Engine Admin
-Cloud Functions Developer
-Cloud Datastore Owner
-Service Account Admin
-Source Repository Administrator
-Storage Admin
So I believe I've come across the solution. After failing to find a predefined role or any answers online, I started to delve into creating custom roles. If anyone has issues with this in the future, here is what I have done.
I went to Project Settings > Roles > Create Role. I then created 2 custom Roles, here are all the permissions I assigned to them:
"Custom API"
container.apiServices.create
container.apiServices.delete
container.apiServices.get
container.apiServices.list
container.apiServices.update
container.apiServices.updateStatus
serviceusage.apiKeys.create
serviceusage.apiKeys.delete
serviceusage.apiKeys.get
serviceusage.apiKeys.getProjectForKey
serviceusage.apiKeys.list
serviceusage.apiKeys.regenerate
serviceusage.apiKeys.revert
serviceusage.apiKeys.update
"Custom Client Auth"
clientauthconfig.brands.create
clientauthconfig.brands.delete
clientauthconfig.brands.get
clientauthconfig.brands.list
clientauthconfig.brands.update
clientauthconfig.clients.create
clientauthconfig.clients.createSecret
clientauthconfig.clients.delete
clientauthconfig.clients.get
clientauthconfig.clients.getWithSecret
clientauthconfig.clients.list
clientauthconfig.clients.listWithSecrets
clientauthconfig.clients.undelete
clientauthconfig.clients.update
*Note that at the time of writing, these individual permissions are in a "testing" state, and may not work as intended.
You can go to the roles page:
https://console.cloud.google.com/iam-admin/roles?project=[your-project-id]
And there you can filter for the permission you need:
Now you can see in the list all the roles include the permission you need, and you can return to the IAM page:
https://console.cloud.google.com/iam-admin/iam?project=[your-project-id]
And select one of those rules:
Related
I'm unable to create a Cloud Function in my GCP project using GUI, but have admin roles for GCF, SA and IAM.
Here is the error message:
Missing necessary permission iam.serviceAccounts.actAs for
cloud-client-api-gae on the service account
serviceaccountname#DOMAIN.iam.gserviceaccount.com. Grant the role
'roles/iam.serviceAccountUser' to cloud-client-api-gae on the service
account serviceaccountname#DOMAIN.iam.gserviceaccount.com.
cloud-client-api-gae is not an SA nor User on my IAM list. It must be a creature living underneath Graphical User Interfrace.
I have Enabled API for GCF, AppEngine and I have Service Account Admin role.
I had literally 0 search results when googling for cloud-client-api-gae.
I've contacted GCP support and it seems my user was missing single role:
Service Account User - that's it.
PS: Person from support didn't know what this thing called "cloud-client-api-gae" is.
Saw the same thing. You need Service account user on the SA you plan to deploy the CF onto. The same incorrect identity was shown.
The user account attempting to create cloud function, need to be given "Service account user" role on the Service account they are using for this cloud function to run on.
As the title says, I have a user "User1" in a group "Techs" and "Techs" is a Role Enabled Azure AD, Cloud Only, Security Group that is assigned both the Exchange Administrator, Helpdesk Administrator and Exchange Recipients Administrator roles.
User1 is able to powershell and use most cmdlets for mailbox management, but is unable to access the EAC. Attempting to access EAC sends User1 to a mailbox management page for their own mailbox, and attempting to Edit Mailbox Properties for a user in the Microsoft 365 Portal greets User1 with a 403 forbidden page.
Direct assignment of exchange admin role works, but defeats the purpose of using a group. Anyone else experience this or know how I can fix it?
Currently, it is possible to switch back to the existing EAC (often called the "classic" EAC), but at a future date, the classic EAC will be retired.
But I suggest not to use "classic" EAC for work because according to my test, the methods listed here cannot allow the exchange admin to manage the mailboxes in the tenant.
It's recommended to access new EAC using these 2 methods.
Sign in to Microsoft 365 or Office 365 using your work or school account.
In the left navigation pane, navigate to Admin centers > Exchange.
You can also get to the new Exchange admin center directly by using
the URL https://admin.exchange.microsoft.com and signing in using your
credentials.
As the document suggests, Be sure to use a private browsing session (not a regular session) to access the Exchange admin center using the direct URL. This will prevent the credential that you are currently logged on with from being used.
In this way, your user which is assigned Exchange Admin role with Group inherit way should be able to access EAC successfully.
This situation made me create a real monstrous work-around, but sometimes, you don't have an option right?
The problem is basically bumping into 503: 'serviceUnavailable' messages when several (specific?) Azure AD Application permissions are set in your Azure AD Application, which should not happen.
Context and technical queries
The context is specifically for Application permissions (app-only auth) and NOT delegated permissions. Token is retrieved by:
HTTP POST https://login.microsoftonline.com/e6fcb01a-f706-4b1b-872b-1e7645d78491/oauth2/v2.0/token
headers:
Content-Type=application/x-www-form-urlencoded
-------------
client_id=<App GUID>
client_secret=<App SECRET>
scope=https://graph.microsoft.com/.default
grant_type=client_credentials
/sites/root query retrieved by:
HTTP GET https://graph.microsoft.com/v1.0/sites/root
headers: Authorization=Bearer <AccessToken>
-------------
Reproduce this situation:
Create an Azure AD Application
Add Application Permission > Sites.ReadWrite.All
Grant Admin Consent for
Create Secret
Generate Access Token (using)
Run Query with token (works)
Forcing it to break (either add all at once or 1-by-1)
Add Application Permission > Group.Create
Grant Admin Consent for
Generate Access Token
Run Query with token (fails?)
Does it work?
Add Application Permission > Group.ReadWrite.All
Grant Admin Consent for
Generate Access Token
Run Query with token (fails?)
Repeat for another permission. until it breaks.
Does it break?
Fails forever
Workaround:
Split up App Permission across multiple AD applications.
I tested this and the issue is there but a workaround is you don't need Group.Create permission if you have Group.ReadWrite.All.
So in summary a single AD app can have Group.ReadWrite.All and Sites.ReadWrite.All permission and it will work but a single AD app will fail if it has all three permissions of Group.Create, Group.ReadWrite.All and Sites.ReadWrite.All
Based on my test (Did not test all permissions), the issue does exist.
There are two main permissions that affect the calling of this API endpoint.
They are Group.Create and Group.Selected.
I'm not sure why they cause the failure of the calling of /sites/root. But it's strongly recommended to remove these two permissions (maybe there are some more other permissions) from the Azure AD app which is used to access /sites/root.
At the same time, opening a support ticket on Azure portal for your Graph request is a good choice.
Unfortunately this was a previously known issue in SharePoint. A fix is on its way but I don't have an ETA for rollout to share.
I'm trying to get a list of all users in my organization (~300), but the /users endpoint only returns two admin accounts.
Our administrator has given the application consent.
Scope: https://graph.microsoft.com/.default
Does it have something to do with the "(Admin only)" marking on the screenshot below?
/v1.0/users returns:
Some permissions do require an Admin Consent and thus have the marking "(Admin only)".
"Admin only" means that only an administrator can consent this permission.
Most delegated permissions (access on behalf a user) do not need an Admin consent, but some like e.g. Agreement.Read.All are only available for administrators.
Since you are using Application Permissions (and getting access without a user) all permissions will have the "(Admin only)" mark. But this does not mean that the returned results are limted to admins.
Seeing you have given the app the permission User.Read.All your app should be able to request a list of all Users with /v1.0/users/ (it will definitely return all users).
The most likely explanation for your results is that you only have two users in your Office365 AD.
Maybe there was an error setting up the users?
I would suggest to login into the Graph-Explorer and check if you get the same results.
And to check in your Azure Admin Portal if all users registered in your AD.
How can I find out what admin permissions are blocking the user from signing in to an Azure AD app?
I am setting up an App Registration in the Azure AD portal to be used with my Service Fabric cluster. The app registration does basic auth and only has one Required Permission configured: Sign in and read user profile (which does NOT require admin permission).
My tenant has the "Users can consent to apps accessing company data on their behalf" setting to "Yes", so it's not that.
Also, the /authorize request doesn't have any resource parameter, so it's implicitly asking for the permission I configured: Azure AD's Sign in and read user profile.
However when an non-admin user attempts to sign it, I still get the error:
AADSTS90094: The grant requires admin permission
I reproduced the scenario and this is what I observed. Found a workaround, hope it helps.
First I created a Service Fabric (SF) cluster secured with AAD authentication using the steps described here, using an AAD tenant where I am not a global admin.
Then I tried to login to Service Fabric Explorer (SFX) and I got this error:
AADSTS50105: The signed in user is not assigned to a role for the
application 'f8c79129-deb7-4a21-a6e0-ec29e88298ef'
This is expected, because the user must be assigned to a role (Admin or ReadOnly) in the SF application that represents the cluster. So I went to AAD > Enterprise Applications > found my cluster app and under Users and Groups I added myself to the Admin role. Notice that the fact that a regular user can administer the roles of an application that the user owns is something new, it's available since a month or so -- before that, a regular user couldn't administer the roles of an application.
Then I tried to login again to SFX and I got a different error:
AADSTS65005: Invalid resource. The client has requested access to a
resource which is not listed in the requested permissions in the
client's application registration. Client app ID:
f8c79129-deb7-4a21-a6e0-ec29e88298ef. Resource value from request: .
Resource app ID: 00000002-0000-0000-c000-000000000000. List of valid
resources from app registration: .
00000002-0000-0000-c000-000000000000 is Windows Azure Active Directory. For some reason SetupApplications.ps1 doesn't assign the Sign in and Read User Profile permission to the SF cluster application. So I edited the application and I assigned that permission, just like you showed in your print screen. Notice that SetupApplications.ps1 has a parameter AddResourceAccess (not mentioned in the doc) that adds that permission, not sure why it doesn't add it by default. Perhaps it isn't needed when you run SetupApplications.ps1 as a global admin, and the scripts/doc assumes that you are a global admin.
Then I tried to login to SFX again and I got the same error that you observed:
AADSTS90094: The grant requires admin permission.
So I checked the SF application under AAD > Enterprise Applications > found the SF cluster app > Properties. User assignment required is configured "Yes". I changed it to "No" and tried to login to SFX. This time it worked OK, I could consent and access the SFX console. Then I changed User assignment required again to "Yes".
One can argue if the SF app really needs User assignment required > Yes because anyway if a user is not assigned to the Admin or ReadOnly role, SFX will try to fallback to client certificate authentication.
In either way, the AAD behavior is confusing. At least, the error should be more descriptive and point to the User assignment configuration. Perhaps the current behavior has to do with what I mentioned before, that regular users can now administer roles. Perhaps the behavior is being improved.