When I create a service principal it also creates an App in Active Directory.
az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/123456a1-a1b2-1234-12ab-12a3b4cdef67"
If I go to the Azure Portal - Active Directory - App registrations it shows all the applications registered.
I have managed to find the service principal I use for terraform by matching the terraform client_id with the Azure "Application (client) ID". It also had a human readable display name (although not the best since I still had to look via client id!)
However, there are several others where the display name is just "project_subscription".
They look like they must have been generated automatically when setting up a pipeline registering a web app in the portal or something.
I can't tell if they are actually used or if they were just created for experimenting and are then left over.
How do I know what they are for and if they are still used or not?
Is it possible to search Azure for the id or anything?
Is it possible to add a description to these to identify what they are used for beyond just the display name?
e.g. I only identified the terraform one by matching up the id with my code
App registration can be used for many scenarios, the app registrations in your AAD tenant should be created by different users. There is no such thing as a description of them.
To see if they are used, it needs to combine the context, as in AAD, there are different usages for them. For example, there are no sign-in logs of the AD App's corresponding service principal, but you cannot make sure if it was used as a client app. For the details, you may need to check the Audit logs.
For more details about AD App(App Registration) and service principal, you could check this doc - https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
Related
I'm trying to improve my knowledge in GCP-GKE as a newbie and in the way to do that, I found out a little concept that I don't quite understand yet. In GKE, there is a Service Account called service-PROJECT_NUM#container-engine-robot.iam.gserviceaccount.com (where the PROJECT_NUM is the ID of our project) and after several hours googling, I couldn't find any article or definition about this stuff. So could you guys please explain to me
What is this Service Account ? How was it created (by who)?
What is this thing for? How important is it in GKE?
What happens if we delete it ? Could we re-created it manually ?
In fact, I found out that in GCP, we have some Service Account that have a "robot" suffix: ...robot.iam.gserviceaccount.com/ (like #gcf-admin-robot.iam.gserviceaccount.com/, #serverless-robot-prod.iam.gserviceaccount.com, etc). What could we say about this, please ?
If I misunderstand something, please, point it out for me, I really appreciate that.
Thank you guys !!!
Service Accounts aka "robots" contrast with user ("human") accounts and represent two forms of Google identity.
NOTE Robots was the original name for Service Accounts and is a more colorful description of the intent of these accounts, to run software.
(Google) User accounts include consumer (Gmail) e.g. you#gmail.com and you#employee.com (Workspace) accounts. User accounts are used by humans to interact with Google services and must be used (or a suitable delegate) to acccess user-owned content such as Workspace docs, sheets etc.
Software ("robots") generally should run as a Service Account not as a User account. In part, you can't easily run software using User accounts because the User OAuth flow is 3-legged and requires interacting with an OAuth Consent Screen to permit an app access to data.
There are two flavors of Service Account: Google-created|managed and User-created|managed. The difference is essentially the owner. If you create applications, generally you should create a Service Account for each app and run the app using its Service Account.
User-managed Service Accounts take the form {something}#{project}.iam.gserviceaccount.com where you get to define the value of {something} and the Google Project in which the Service Account is created (the project that owns the Service Account) is represented by {project} (actually the Project ID).
When Google provides app functionality, it also creates Service Accounts and often, Google "binds" these Service Accounts to your projects that use them in addition to defining the role that the Service Account has in your project.
Google-managed Service Accounts take the form {something}#{label}.iam.gserviceaccount.com. Unlike User-managed Service Accounts, Google uses more descriptive labels ({label}) to help explain the role of the Service Account.
NOTE With Google-managed Service Accounts {something} often includes the Project Number (not ID) of (your!) project for which the Google-managed account has been created.
You cannot delete Google-managed Service Accounts because you(r Google account) does not own the Service Account.
You can (but should not) delete the role binding between one of your projects and a Google-managed Service Account. It may be possible for you to revert (recreate) the binding but you may not have permission to do this.
I couldn't find it anywhere but was wondering if there is a rest api way that allows to programatically register an application (besides the documented ones (powershell,CLI and by portal). I have an app that needs to access to azure monitor to retrieve some metrics and didn't want the clients to have to register the app by themselves. So it would be something like this:
https://learn.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-rest-api-walkthrough
but that I could use in javascript for example.
Thanks!
The reason that the PowerShell sample in the above document works is because Azure PowerShell is registered as an Active Directory application already. At some point, your application will have to be added manually by the customer, since Active Directory APIs can't be executed by a user role.
Take a look at New Azure AD application doesn't work until updated through management portal for the steps necessary to create an application via the Azure AD graph API.
I created a new AAD user without any special permissions (no admin, just a user). Now, when I login using the Connect-MSOLService cmdlet and retrieve all users using Get-MSOLUser I can see every user within that directory.
Why and am I able to change that?
Background: I want to use a single AAD instance for multiple SAAS applications and want to prevent that a user can browse all users.
Actually, there is a way to disable user browsing in an AAD using the Set-MsolCompanySettings from the MSOnline module:
Set-MsolCompanySettings -UsersPermissionToReadOtherUsersEnabled $false
In Azure AD, Users and groups are created in a flat structure without OU and GPO. You can't restrict the user's permission to a specific scope. The user can view all the user information in Azure AD.
To isolate the users from different scopes, you can create multiple directories for Azure AD, and configure the SaaS applications as multi-tenant application for AAD.
You can refer to the article below for more details about Azure AD Directory role.
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-assign-admin-roles
If you connect to an Active Directory you usually want to read some data. As such if you're authorized to do that you can easily access information that is available and particularly "sensitive" (e.g. you can't read private keys of user objects easily). If you look at the history of Active Directory and it's typical usage within companies, it's likely that only single tenant (company) using it at a given time. As such there were even less reason to restrict the access.
If you want to have multiple tenants use the same AD you will have to figure out a scheme that works for you and setup the proper permissions yourself.
Helpful articles for this could be:
Build a multi-tenant SaaS web application using Azure AD & OpenID Connect
Question: Creating a multi-tenant AD environment
The Problem
MS Azure provides an extensive REST API. However, there is a significant amount of complexity when trying to get that API to work. From outdated and incomplete documentation to simple examples not working, performing what should be an easy task is instead nightmarish.
The Task
What are the exact, precise, detailed steps necessary to list the available VMs for someone who has logged in using Oauth2? For instance, this can be done using the azure-cli.
azure vm list
What are the steps to accomplish the same thing using REST and Oauth2?
The Requirements
The answer must not use Visual Studio, PowerShell, C#, an SDK, or any other such tool to accomplish this task. Only the portal is allowed for setup, and only Oauth2 is allowed for authorization, and only the REST API is allowed for actual information retrieval.
The answer must not simply link to external sources, although external references are encouraged for completeness.
The answer may assume the user has an Azure account. It must include information about creating the Oauth2 client, credentials, and any step necessary to get the appropriate token.
The answer must be detailed.
The answer must provide examples. Images, too are strongly encouraged.
The answer should include information about possible errors, their meanings, and what too look for to fix them.
First, we can find this rest API in azure resource portal. It is the same with Azure CLI command azure vm list.
I have tested it on my local with http request. here is my tested screenshot:
Request URL: https://management.azure.com/subscriptions/<subscription ID>/providers/Microsoft.Compute/virtualMachines?api-version=2016-03-30
Header:Authorization: bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI.....
So It is very import if we get the access token. The following demonstrate us how to get the access token.
Get Token(POST):
Request URL: https://login.microsoftonline.com/<tenant id>/oauth2/token
Body: grant_type=client_credentials&client_id=<client id>&resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_secret=<client secret>
Here is my screenshot in fildder:
We need to get client id and client secret in azure ad application. For how to regist an application in Azure AD. Please have a look at this article: https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal.
Please note:
1) we need to add "Windows Azure Service Management API" in portal "Required permissions" like the following screenshot:
2) We need assign "Contributor" for this service principal. click subscription-> Access Control-> click Add -> click "Select a Role" -> click Contributor->click Add User-> Find the application you created above-> click OK.
Overview
Making requests against the Azure Rest API is a bit more complicated than perhaps you would think at first glance. In particular, there are a number of esoteric and not-so-helpful error messages you may run into while getting the nobs tweaked just right.
Introduction and Terms
Setting up The Application
Getting the access_token
Making the API request
Common errors thus far
Introduction and Terms
One of the pieces of this process that can make it so confusing and difficult is the terminology. Until you understand that, knowing how to deal with errors is very difficult. We'll go over some of the more common ones here.
Subscription - This is basically what you'd expect. It refers to the Microsoft Azure Services subscription. It basically acts as the top-level umbrella for the organization.
Tenant - This is like a sub-organization, maybe a department or group. There can be multiple tenants under a single subscription.
User - As expected, a user is a single individual. Users are scoped to tenants.
Application - The Application is the software program trying to use the API. It must be registered and configured to do so.
Service Principal - This is essentially The Application. It is the entity making API Service requests.
Setting Up the Application
Although you might not guess it, this is probably the most complicated part of the process. Let's start by creating The Application in the portal.
Create The Application
Follow this click path: Azure Active Directory -> App Registrations -> New
There should be a form for application creation, with the following fields:
Name
This is simple the name of The Application. When authenticating, it will be shown to users. For the purposes of this "tutorial", we'll call it API Tutorial. This can be edited after creation.
Application Type
The type of The Application. For our purposes, we should choose "Web app/API". This cannot be edited after creation.
Sign-on URL
The is the redirect that will be used if we go the "authorization_code" route for sign on. This can be useful as the response will include an "id_token". We'll get into that a bit later. For now, let's make this http://123AzureApiTutorial.com/code. This can be edited after creation.
Once the Application has been created, you should see a property, Application ID. This is the client_id used in the OAuth2 flow. Take a note of its value.
Create the Client Secret
The OAuth2 flow requires a client secret value for authentication.
To generate it, follow this click path: Azure Active Directory -> App Registrations -> API Tutorial -> All Settings -> Keys
Enter the key description: API Tutorial Key, and the Duration: In 1 year.
Click Save. This will generate the Key Value. You must copy the value here and save it somewhere. You will not have another opportunity to do so.
This value is the client_secret in the OAuth2 flow.
Add the correct permissions
To get to the permissions, follow this click path: Azure Active Directory -> App Registrations -> API Tutorial -> All Settings -> Required Permissions -> Add
Here you will see the list of possible APIs. The one we care about for Azure is Windows Azure Service Management API. There is currently only one permission: Access Azure Service Management as organization users (preview). Select it, click Select, and then Done.
Getting the access_token
The access_token is what allows us to make requests against the API. There are two primary ways to do this. I suggest reading about both before trying to implement them.
Authorization Code
The authorization code is a two-step process. First we obtain the authorization code, and then we use that to get the access_token. A benefit of this route is that we get back an id_token as well, with a variety of useful claims like the user's name, email address, etc.
The request format is as follows: (GET) https://login.microsoftonline.com/<tenant-id>/oauth2/authorize?client_id=<client-id>&scope=api&redirect_uri=<redirect-uri>&response_type=code&prompt=consent. Let's go over the parameters here really quick.
Tenant ID
This can be obtained be using the click path Azure Active Directory -> Properties and copy the Directory ID. This is, in fact the Tenant ID value. It just has a different name to help with the overall confusion.
Client ID
This is the Application ID we retrieved previously.
Scope
This is the scope of the code. We just want to use the API.
Redirect URI
This is the sign-on URL you specified when creating API Tutorial. After the user logs in, they will be redirected to this URL with a "code" parameter in the query string.
Response Type
This is what we want the response to be. We want an authorization code, so we just use the value code.
Prompt
This specifies whether or not to prompt the user to consent to the permissions. If we did not have this, and changed permissions, the request would just unexpectedly fail. Very frustrating. But it can be removed once permission has been granted as long as you don't change the permissions. If the application is accessing an API that requires admin permission, this value should be admin_consent.
Alright, so once we shoot off this request we will be redirected to the login page. We login, accept the permissions, and then we should be redirected to here: http://123AzureApiTutorial.com/code?code=SOME_REALLY_LONG_STRING_OF_CHARACTERS. That string of characters is the code.
Getting the Access Token
Next, we take the code and use it to get the access_token. To do so, we need to make another request.
(POST) https://login.microsoftonline.com/<tenant-id>/oauth2/token
In addition to the url, we need to add parameters. These should be consistent with the content type application/x-www-form-urlencoded. This means they are submitted as form parameters. They are as follows:
client_id
This is again the client id (Application ID) we already have.
client_secret
This is the Application Key we generated earlier. I hope you saved it! If not, go back to that step and generate another one.
code
This is the value of the code we just received: SOME_REALLY_LONG_STRING_OF_CHARACTERS.
`grant_type
Because we're going the authorization code route, this value should be authorization_code
redirect_uri
This is the redirect uri we specified for the API Tutorial. The value from our example should be http://123AzureApiTutorial.com/code.
resource
This is very important. It is the resource API we want to access. For the Azure API, this value is https://management.azure.com.
Our response will be a json object with a variety of fields. Of these, the one we care about is access_token. Yay!
Client Credentials
This methodology skips getting the code (and thus needing the redirect_uri) at the expense of not getting an id_token.
The request is the same as in the Getting the Access Token section, with a few small differences.
We do not need to specify redirect_uri.
The value of grant_type should change to client_credentials.
Alright, we have an access_token! Now we're cooking!
Making the API request
With all the prep work thus far, this is the easiest part of the process.
The API URL we are requesting against is:
https://management.azure.com/subscriptions/<subscription-id>/providers/Microsoft.Compute/virtualMachines?api-version=2016-03-30
Add the following header to the request:
Authorization: Bearer <access-token>. Yes, the access_token value must be prefaced with the word "Bearer" in the header value.
"But wait!" You exclaim. "How do I get the subscription id?"
Excellent question! To find it through the portal, click Subscriptions -> -> Overview and copy the Subscription Id value.
Use that value, and run the request. You should see all the vms listed!
Common errors thus far
InvalidAuthenticationToken
When making the API request, you get an error response that says something like this: InvalidAuthenticationToken: The access token is invalid. This means you haven't added the API permissions to the API Tutorial. Go back to the Add the correct permissions step and double-check you have the right permissions. Also, when requesting the token make sure you use the prompt=consent, otherwise the you will not be prompted with the new permissions and the token will fail.
InvalidAuthenticationTokenTenant
Make sure that the tenant-id used when requesting the token belongs to the subscriber used when making the API call.
I have an existing application with a few thousand users using SqlAzureMembershipProvider for authentication.
I am interested in creating an Azure Active Directory for the application and migrating the existing membership profiles into it.
Is it technically possible to export/import the membership profiles?
The only approach I can think of is creating a PowerShell script that gets user details from the app one by one and creates a new user for each of those in the new AD.
Yes it is possible but there are no tools to do this.
For AD e.g. there is DirSync.
Probably easiest to use the Graph API - refer: Azure AD Graph API - samples Microsoft Azure Active Directory Samples and Documentation.
As you say, you will have to cycle through the users one by one. The password is going to be a problem. You may have to give each user a dummy password to start.