I wrote a skill that requires permission to the user email. The problem is I can't share the permission in the development mode and give access to the app. Also, I can't share the app with test users because they will also face the same problem.
My question is how to exactly give email permission when the app is in development mode?
Thanks,
H
Related
I'm currently trying to invite another developer to my gcloud project as an owner. For this I go inside the IAM and grant him access via his gmail account. He receives the invitation e-mail, clicks on "accept invitation" and then has full access rights on the project. However in the IAM it still says:"Invitation sent. Pending acceptance.".
In consequence he's not able to deploy any new AppEngine builds as gcloud CLI fails reporting he does not have the necessary access rights. Anyone experience the same issue? I already checked the e-mail address multiple times as well as wait for several days (so permissions are properly set), but nothing changed. Thanks!
While waiting or solving the email invite, assign normal resource-based IAM roles granting permission.
Except for special cases, the Owner role should not be used or granted to users.
You, as project owner, should not be using an account with the Owner role. That role should be assigned to an identity that is locked away for use when required.
I have created an Azure AD app registration for a cross-platform (Xamarin.Forms) mobile application for our employees. The app registration is setup to work as a single-tenant app and in order to function properly, we have specified a number of permissions to Microsoft Graph, such as "openid", "profile", and "User.Read", which have been given admin consent by our Admin. The app uses broker authentication (using ADAL) in order to sign-in users to the app via the Intune Company Portal app already installed and setup on every user's device.
Up until recently, everything worked fine until we needed to add a new Microsoft Graph permission to the app registration, namely "Group.Read.All". So, we added the new permission to our app registration as a delegated permission and had our admin provide the admin consent for all the users.
After giving consent to the new permission, our users could not login to the app since the Intune Company Portal app did not sign-in the users to the app, but instead advised them to setup their device by installing and setting up the Intune Company Portal app on their device (?!).
As I mentioned before, the devices already had Intune Company Portal installed and properly setup on their device for more than 2 years now.
So, we thought of checking the user sign-ins of the user to find out what the problem was and we found a failure event recorded with sign-in error code 530003 (Access has been blocked due to conditional access policies.) where it showed that the policy "Access Policy: Require Device Enrollment for Accessing EOL & Sharepoint from handheld devices" failed with reason "require compliant device" (under column Grant Controls).
As soon as we revoked the newly added permission "Group.Read.All" from the app registration, our users could sign-in to the app successfully.
When we tried adding other permissions like Directory.Read.All and GroupMember.Read.All, we did not have any issues with our sign-in flow via the Intune Company Portal.
Can you please advise what it is so special about the "Group.Read.All" permission that raises the Azure sign-in error code 530003, forcing the Intune Company Portal app to require the users to setup their (already setup) device, before they can sign-in to our app?
I am at my wits' end with this one.
Any ideas?
For me it is not possible to reproduce your issue due to multiple things involved.
Few suggestions that you could try at your end:
Try isolate each component and leverage graph explorer/postman to make an API call and observe behavior.
I didn't get the need to add graph permission, but as per your use case see if there is any other least privileged permission that could get your job done, add that permission and check behavior.
Check if your scenario really demanded adding permission as delegated and if this is really supported? For e.g, below image shows necessary permssion to get the properties and relationships of a group object.
If problem still persists, consider contacting Microsoft support for your specific scenario.
So I have registered a new multi-tenant AAD application but trying to log in using the same account I created it with gives me the error
MSAL.Desktop.4.5.0.0.MsalServiceException:
ErrorCode: invalid_client
Microsoft.Identity.Client.MsalServiceException:
AADSTS650051: "Using application 'TestApplication' is currently not supported for your organization sample-company.ch because it is in an unmanaged state. An administrator needs to claim ownership of the company by DNS validation of sample-company.ch before the application TestApplication can be provisioned."
The domain name in question is already verified, so im not sure whats wrong here. After registering the app I just followed their Windows Desktop App Quickstart Guide and tried logging in with their sample project
https://github.com/Azure-Samples/active-directory-dotnet-desktop-msgraph-v2/
Any help would be appreciated
Since your application is for multi-tenant, you probably didn't do user or admin consent for the target tenant.
Try to add &prompt=admin_consent in your request to force admin consent. Log in with an admin account to do admin consent.
Please see details from Understand user and admin consent.
My organization is taking a look at the security of registered applications within Azure Active Directory (AAD) and have concerns around the ability of individuals to add client secrets and certificates for applications that are using the "application permissions" model. I'm working to help narrow the roles of individuals within the organization to restrict this, but this investigation begged the question of what a malicious insider could do if he or she could add a client secret to this application.
I've looked through the 30 Days of Microsoft Graph blog series, which is excellent, but wanted to clarify what else can be done to prevent an insider from gaining access to the permissions this application would allow.
Does the redirect URL itself protect against this kind of scenario, provided the organization retains control of all registered URLs (meaning, for example, that https://localhost isn't registered)? Based on this post under Step 3, I assume the answer is yes but wanted to make sure this is the case.
Is it technically correct to say that without the redirect URL being secured/owned by the organization, a malicious insider who could add client secrets could exploit the permissions granted by the application?
If you are able to add a client secret to an app that already has been granted application permissions to something, then this user can use the new secret to get tokens and access those resources as the app.
Redirect URL is not used with application permissions, only delegated permissions.
This is because there are no redirects in the client credentials grant flow, which is used when acquiring a token with app permissions.
It's just an HTTP request.
So you are correct in your assumption that being able to add a new secret to an app that already has permissions can be a security issue.
There are audit logs though, and I believe adding a secret/certificate is logged.
My initial version uses the built-in GAE Users Service for application login/registration.
However, I was not able to revoke the app's permissions from my Google account settings.
https://security.google.com/settings/security/permissions
Google has updated the dashboard.
I think they missed a feature to allow users to revoke GAE apps permissions.
Can someone help me verify this?
If you are talking about this [1] built-in service, your app have access to the user's email address as well as a unique user ID only while the user is signed into your app. So there is no permanent permissions to be revoked.
[1] https://cloud.google.com/appengine/docs/python/users/