I have been working with the Android Management API to try and manage the policy of my company's existing enterprise. My company account has the Owner role within the organization and the roles Owner and Service Account Admin for the service account mentioned later.
I followed the Quickstart Guide to get familiar with the API and made some modifications for a more permanent solution along the way such as creating a service account with the Android Management User role via the Google Cloud Platform and generating a JSON key to acquire credentials rather than going through the OAuth2 flow like in the guide. This allowed me to authenticate properly, but when it comes time to patch the policy as such,
androidmanagement.enterprises().policies().patch(
name=policy_name,
body=policy_json
).execute()
I get the following error:
<HttpError 403 when requesting https://androidmanagement.googleapis.com/v1/enterprises/XXXXXXXXX/policies/<policy_name>?alt=json returned "Caller is not authorized to manage enterprise.". Details: "Caller is not authorized to manage enterprise.">
I have verified that the service account I am authenticating with has the Android Management User role, and thus has the androidmanagement.enterprises.manage permission.
I have also attempted to make this call with an elevated admin role in the organization.
Is there a chance that I need to have created the enterprise with my own account to manage the enterprise? The guide suggests that an organization can create multiple enterprises. In which case, would I need to create a new Google account not associated with my organization's enterprise and create a new enterprise that way?
It is advisable to use your own google account to call Android Management API since your organization account may not be compatible with the quickstart.
To access the Android Management API your service account requires the androidmanagement.enterprises.manage permission, which can be granted by the Android Management User role (or roles/androidmanagement.user). Kindly check this link for details regarding creating a service account.
Please keep in mind that the enterprise you created as part of the colab instructions can only be managed using the colab itself. To allow your cloud project to manage an organization, you will need to create one using the client configuration from your cloud project.
Related
When I want to use Google's Gmail API within my web application in order to receive and send emails, then must this web application be deployed in the Google Cloud as a precondition and any on-premise hosting will fail? Is this the price one must pay to use it?
Your application's code can be hosted anywhere you want. However, you do need to create a Google Cloud account to create a project, enable the APIs and get the application credentials:
Cloud APIs use application credentials for identifying the calling applications. Credential types include API keys, OAuth 2.0 clients, and service accounts. You can use Google Cloud console to create, retrieve, and manage your application credentials. For more information about application credentials, see Authentication Overview.
Once you have your project's credentials you can just create the code within your current app and use the credentials wherever they are needed. You can refer to one of Google's quickstarts for that.
Sources:
Getting started with Google Cloud APIs
Developing on Google Workspace
Gmail API Overview
Here in my company we use G-suite, and it's not possible to create enterprises using our accounts. So, it's possible to create enterprises using services accounts?
Thanks.
You can’t use a service account to create enterprises. Service accounts are used to authorize API access when you build a server-based EMM solution.
To create an enterprise you need a Gmail account that's not already associated with an enterprise. I suggest checking this documentation for more information.
I am using Microsoft Graph API to send messages to private users in Microsoft Teams. I registered an App in Azure Active Directory, gave proper permissions and called the API and was able to successfully send the message.
My question is what would be the most efficient way to deliver this integration to different clients? Do we have to register an App in every azure directory of the client individually, or is there a way I can publish the app that I have created with all the API permissions required and the administrators can install the app in their azure directory
You would have to publish your application in your home tenant as a Multi-tenant application.
When a user from the client's tenant access your app, they will be prompted for login and post that either the user or an admin will have to consent to the app and the required permissions. This will create a service principal in the corresponding user's directory where the consent objects are stored. This way you don't have to register application in each directory.
You can follow the steps listed here for more detailed instructions to convert your application into a multi-tenant app.
We have almost 16 users in our Azure DevOps Organisation. I am having the admin privilege for the azure account. I saw a few blogs regarding Active Directory Enabling method and all. But it was not clear.
How can we manage this restriction in Azure DevOps.
NB:-Our users are accessing Azure DevOps through their outlook account.For ex:-sample.orgnization#outlook.com
Depending on your setup, there are a couple of options:
Azure DevOps configured as MSA backed with AAD guests in Azure DevOps
When your Azure DevOps account is configured to be backed by Microsoft Accounts (formerly Live IDs, or Outlook.com or Hotmail.com), it can add Azure Active Directory users as guests into the account. This feature was added last autumn.
In this configuration, you can invite AAd and MSA users directly from Azure DevOps and the MSA users don't get any access to the Azure account.
Azure DevOps configured as AAD backed with MSA guests in Azure Active Directory
When your Azure DevOps account is configured to be backed by Azure Active Directory, it can only add users who are known in Azure Active Directory. However, you can invite Microsoft Accounts into your AAD as guests. You can even invite users from other AADs as federated guests.
In this configuration you can only invite users who are known by AAD into you Azure DevOps account. If they're not in AAD, you'll have to invite them into AAD first.
Switching
You can switch the account between the different association modes. To migrate existing users from one type to another (AAD->MSA, MSA->AAD) you currently need to open a support request to get all of the users mapped over. In this scenario you get an excel export from your account and you provide a mapping between the old and the new uesr account. Support will mapthem for you.
Manual process
You can also take a manual approach. This model isn't well documented. And when manually mappign you'll have to re-apply the security permissions manually as well. As such, thsi approach isn't recommended.
Once in AAD
Once your users are all in Azure Active directory, you can set policies on their access patterns, restrict IP addresses, require 2FA tokens and such. The value is questionable for external users as it won't work for all guest types. It will be valuable for your own users. You can enforce policy on users in your AAD. It's recommended to work with your federation partners to ensure that they're also using the right policies for their own users.
I think this will help you, I also faced the same problem which I mentioned, this article explained in details very clearly that how we can apply 'Conditional Access Policies' to avoid unauthorized access on Azure repositories(Code). after apply the policies on Azure portal, We need to enable the option on dev.portal Enable Conditional Access for Azure DevOps, Hope this will helps you.
I am curious to know why we always need to register our CRM online instance on an Azure Active Directory in order to authenticate the Web API while accessing from outside CRM domain.
That is, for example, if I need to access CRM online instance through another website using CRM's Web API endpoint, then I must register my CRM instance to Azure Active Directory.
Though I am aware that, its a very nominal charge to create an Azure Active Directory, still I would need to subscribe to Azure even if I just want to perform some general research for CRM connectivity through Web API.
Why this is must? Are there any security considerations behind this?
Why can't we use the same authentication mechanism as we used to do with Organization service?
Any details on this will be much appreciated.
The CRM WebAPI uses OAuth2 and Azure AD is the only currently supported authentication platform to provide this (Windows Server 2016 will support OAuth2 for on-premise).
The Organisation service is a WCF service and as such uses SOAP for authentication and authorization. This is an entirely different technology stack that brings it's own set of problems, many of which the OAuth2 protocol tries to solve in this scenario.
Although you manage your CRM Online users through the Office 365 portal the underlying technology for these accounts is also Azure AD. Check if you can use this existing AD tenant created as part of your subscription rather than having to create another.
If you are using CRM online you already have aan Azure Active Directory. If you haven't already done so, you can signup for an Azure subscription and import the underlying AAD into your Azure subscription. You will need a credit card, but as far is I know using the Azure AD is free.