Azure Managed Identity Resource for AKS - azure

I'm trying to follow the guide outlined at this link to generate an access token for AKS for the system assigned managed identity.
The code snippet at the link is doing the following from an app service kudu console:
$resource = "https://graph.microsoft.com"
$endpoint = $env:IDENTITY_ENDPOINT
$header = $env:IDENTITY_HEADER
$apiVersion = "2019-08-01"
$headers = #{ 'X-Identity-Header' = $header }
$url = "$($endpoint)?api-version=$apiVersion&resource=$resource"
$response = Invoke-RestMethod -Method Get -Uri $url -Headers $headers
$response.access_token
Although this snippet works, the resource identifier varies depending on the resource for which you're requesting the access token. I'm not sure what resource value must be specified to get this for AKS. I have found it for the following, but not for AKS:
https://servicebus.azure.net
https://graph.microsoft.com
https://management.azure.com
https://database.windows.net
https://relay.azure.net
https://eventhubs.azure.net
Does anyone know what this ought to be for AKS?

Figured it out. Apparently after deploying AKS a new Microsoft generated enterprise application is created under your tenant called "Azure Kubernetes Service AAD Server" and has a universal GUID:
6dae42f8-4368-4678-94ff-3960e28e3630.
This should be used as the resource.
Surprisingly there's no mention on any Microsoft authored documentation regarding this. Stumbled across this on other sites.
Hope this helps someone else.
Some references:
Reference to this on github
Reference to this on related SO post

Related

Creation of the b2c-extensions-app by script

When you create a ADB2C Tenant Resource, an application registration is also created, named b2c-extensions-app. Do not modify. Used by AADB2C for storing user data. This is a special application which is needed for crud operations.
Around the internet and in the docs, it is mentioned that it gets created automatically, but that's not the case. It is created only after you login into that tenant and go to app registrations, it is a trigger of some sorts. How do I know this? I reached to Microsoft support.
My question: this interferes with some of my automation scripts. Does anyone know of an endpoint to which I can make a rest request so this app gets created.
Okay, after a lot and I mean a lot of trial and error, I finally found the endpoint that causes the creation of that app. I will show a code snippet in PowerShell.
$context = Connect-AzAccount ...
# Aquire an access token from the resource: https://management.core.windows.net/
$tokenItem = [Microsoft.Azure.Commands.Common.Authentication.AzureSession]::Instance.AuthenticationFactory.Authenticate(
$context.Account,
$context.Environment,
$TenantId,
$null,
'Never',
$null,
'https://management.core.windows.net/')
Invoke-WebRequest -Uri "https://main.b2cadmin.ext.azure.com/api/tenants/GetAndInitializeTenantPolicy?tenantId=<your_tenant_name>&skipInitialization=false" `
-Method "GET" `
-Headers #{
"Authorization" = "Bearer $($tokenItem.AccessToken)";
"x-ms-client-request-id" = ([guid]::NewGuid().Guid)
}

Create Azure AD Tenant from command or API

I have been working on creating New Tenant from API or Command Line in Azure Active Directory and I could not find a way to do it.
I have been also using Azure GraphAPI but it doesn't support this.
Is there any way from command or API that I can use to automate creation of new tenants?
I have researched on google and stackoverflow, but I didn't find any way to do it from command or API.
and is there any plan of Microsoft to provide such API in future? (edited)
There's no public, documented or supported (by MSFT) API available for this. That being said you might try using the portal internal API with something like this:
Invoke-WebRequest -Uri "https://main.iam.ad.ext.azure.com/api/Directories" `
-Method "POST" `
-Headers #{
"Accept-Language"="en"
"Authorization"="Bearer <azure ad access token issued for aud=74658136-14ec-4630-ad9b-26e160ff0fc6>"
} `
-ContentType "application/json" `
-Body "{`"companyName`":`"<company name>`",`"initialDomainPrefix`":`"<initial domain prefix (the one that will be appended to onmicrosoft.com)>`",`"countryCode`":`"<iso (2 letter) country code>`"}"

Get Azure DevOps service connection service principal id with powershell

I am working on automating Azure Active Directory App Registrations and Azure Devops Service Connections, and have hit a wall.
I want to query Azure DevOps service connections (service endpoints) by Service Principal ID (or at least get the id). This is possible when using Azure CLI:
az devops service-endpoint list --query "[?authorization.parameters.serviceprincipalid=='xxx']"
But since I am running this in Azure automation account as a powershell runbook, the Azure CLI is not supported.
Then I tried the Azure DevOps REST API, and called it from powershell, but the response does not contain the service principal ID, but just this:
authorization : #{parameters=; scheme=ServicePrincipal}
Does anyone have an idea on how to solve this?
UPDATE
I am calling the rest API like this:
$uriAccount = $UriOrg + "_apis/serviceendpoint/endpoints?endpointNames={name}&api-version=6.1-preview.4"
$result = Invoke-RestMethod -Uri $uriAccount -Method get -Headers $AzureDevOpsAuthenicationHeader
And $result.value gives me this:
authorization : #{parameters=; scheme=ServicePrincipal}
You can try the REST API Endpoints - Get Service Endpoints By Names.
GET https://dev.azure.com/{organization}/{project}/_apis/serviceendpoint/endpoints?endpointNames={endpointNames}&api-version=6.0-preview.4
In this REST API, you can find the id and details by the name of a service connection.
Here is an example to use the REST API in PowerShell:
$token = "{pat}"
$token = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($token)"))
$url="https://dev.azure.com/{organization}/{project}/_apis/serviceendpoint/endpoints?endpointNames={endpointNames}&api-version=6.0-preview.4"
$head = #{ Authorization =" Basic $token" }
Invoke-RestMethod -Uri $url -Method GET -Headers $head
Update:
The cause for this question is that you output result in the wrong way.
For JSON response bodies, there is no intuitive way to get results without specifying the final layer.
Here is my modified code, notice how I print result:
$token = "{pat}"
$token = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($token)"))
$url="https://dev.azure.com/{organization}/{project}/_apis/serviceendpoint/endpoints?endpointNames={endpointNames}&api-version=6.0-preview.4"
$head = #{ Authorization =" Basic $token" }
$reslut = Invoke-RestMethod -Uri $url -Method GET -Headers $head
echo $result.value.authorization.parameters

Cannot set "preAuthorizedApplications" object in new App registrations module through Azure Powershell

Short Scenrario: A muti tenant front end javascript (React.JS) Web Application calls a multi tenant ASP.NET Core 2.2 WebAPI from the browser.
Authentication:
ADAL.js in the front end app takes care of getting a token from either AzureAD1 or AzureAD2 or AzureAD3... when the User signs-in (based on the User's original Azure Active Directory).
The User gives consent to the front end Web App (scope: Sign in and read user profile) which is delegated to the WebAPI too. (meaning the user does not need to consent to the WebAPI as well)
The front end Web App calls the WebAPI with the bearer token to get the resources.
Problem: I must automate the deployment of a new environment. And set the manifest file accordingly (It's a SaaS solution)
In the manifest file I need to expose the WebAPI for the client application (https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-expose-web-apis#expose-a-new-scope-through-the-ui)
Setting "knownClientApplications" is not enough (due to previously described delegation)
The new v2 endpoint (https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-overview) has a new App Registration feature. The old one is called "Legacy" now and will be deprecated starting May 2019.
In the Azure Portal need to expose the API and add the front end WebApp as an "Authorized cient applications".
This step will add a new object in the manifest file:
"preAuthorizedApplications": [
{
"appId": "guid",
"permissionIds": [
"guid"
]
}
],
But it's still not available throuh PowerShell! (https://learn.microsoft.com/en-us/powershell/module/azuread/set-azureadapplication?view=azureadps-2.0)
How can I add this "preAuthorizedApplications" section into the manifest file using Azure PowerShell? Why is it available in the portal but not in PS yet? It's the other way around usually...
08-05-2019 Update based on the answer:
I am getting the access token via a Service Principal:
$adTokenUrl = "https://login.microsoftonline.com/$TenantId/oauth2/token"
$resource = "https://graph.windows.net/"
$body = #{
grant_type = "client_credentials"
client_id = "$ServicePrincipalId"
client_secret = "$ServicePrincipalKey"
resource = "$resource"
}
$response = Invoke-RestMethod -Method 'Post' -Uri $adTokenUrl -ContentType "application/x-www-form-urlencoded" -Body $body
$token = $response.access_token
According to the docs: https://learn.microsoft.com/en-us/graph/api/application-update?view=graph-rest-beta&tabs=cs
The Service Principal should have at least Application.ReadWrite.OwnedBy, and most Application.ReadWrite.All privileges.
Should I ask our AAD admin to grant the below rights to the Service Principal?
08-05-2019 Update 2: Service Principal has been granted with ALL of the highlighted rights above.
Attempt 1:
Step 1: getting an access_token via the Service Principal (Owner of the Api app to be updated)
$adTokenUrl = "https://login.microsoftonline.com/$(TenantId)/oauth2/token"
$resource = "https://graph.microsoft.com/"
$body = #{
grant_type = "client_credentials"
client_id = "$(ServicePrincipalId)"
client_secret = "$(ServicePrincipalKey)"
resource = "$resource"
}
$response = Invoke-RestMethod -Method 'Post' -Uri $adTokenUrl -ContentType "application/x-www-form-urlencoded" -Body $body
$token = $response.access_token
Step 2: using this access_token, building up my PATCH request as per Md Farid Uddin Kiron's suggestion, and
Result: The remote server returned an error: (403) Forbidden.
09-05-2019 Update 3: After some kind and detailed explanation and guidance, I got this to work and getting HTTP 204 for my Postman request. Only thing left is to integrate this steps into my pipeline.
See accepted answer. It works. If someone has the same issue,
please read the other answer from Md Farid Uddin Kiron.
If you want to avoid calling directly the graph API (maybe you are in an azure pipeline using a Service Connection and don't have access to the credentials) you can do this :
$AppName = << WebApp >>
$preAuthorizedApplicationsAppId = <<GUID>>
# Get the application and delegated permission to pre-authorize
$appRegistration = Get-AzureADMSApplication -Filter "displayName eq '$AppName'"
$oauth2Permission = $appRegistration.Api.OAuth2PermissionScopes | Where-Object {$_.Value -eq $AppName -and $_.Type -eq 'Admin'}
# Build a PreAuthorizedApplication object
$preAuthorizedApplication = New-Object 'Microsoft.Open.MSGraph.Model.PreAuthorizedApplication'
$preAuthorizedApplication.AppId = $preAuthorizedApplicationsAppId
$preAuthorizedApplication.DelegatedPermissionIds = #($oauth2Permission.Id)
$appRegistration.Api.PreAuthorizedApplications = New-Object 'System.Collections.Generic.List[Microsoft.Open.MSGraph.Model.PreAuthorizedApplication]'
$appRegistration.Api.PreAuthorizedApplications.Add($preAuthorizedApplication)
# Update the Application object
Set-AzureADMSApplication -ObjectId $appRegistration.Id -Api $appRegistration.Api
This answer comes from this GitHub issue.
You are right, seems there is something faultiness exists in AzureAD powershell module. That not works for me too .
If you want to modify your app manifest using powershell to add "preAuthorizedApplications" section, you can try the powershell script below.
I have tested on my side and it works for me.
In theory, I have called Microsoft Graph API to modify the app manifest . If you have any further concerns, please feel free to let me know.
$AdAdminUserName = "<-your Azure ad admin username ->"
$AdAdminPass="<-your Azure ad admin password ->"
$AdAppObjId = "<-your app obj id->"
$AdPreAuthAppId = "<-the app that need to be pre authed ->"
$AdAppScopeId = "<-your app scope id->"
$tenantName = "<-your tenant name->"
$body=#{
    "grant_type"="password";
    "resource"="https://graph.microsoft.com/";
    "client_id"="1950a258-227b-4e31-a9cf-717495945fc2";
    "username"=$AdAdminUserName;
    "password" = $AdAdminPass
}
$requrl = "https://login.microsoftonline.com/"+$tenantName+"/oauth2/token"
$result=Invoke-RestMethod -Uri $requrl -Method POST -Body $body 
$headers = New-Object 'System.Collections.Generic.Dictionary[String,String]'
$headers.Add("Content-Type","application/json")
$headers.Add("Authorization","Bearer " + $result.access_token)
$preAuthBody = "{`"api`": {`"preAuthorizedApplications`": [{`"appId`": `"" + $AdPreAuthAppId + "`",`"permissionIds`": [`"" + $AdAppScopeId + "`"]}]}}"
$requrl= "https://graph.microsoft.com/beta/applications/"+$AdAppObjId
Invoke-RestMethod -Uri $requrl -Method PATCH -Body $preAuthBody -Headers $headers
Note: ROPC is not safe as Microsoft does not recommend to use that. It also does not allow to use MFA that is why it is little
dangerous.
Some additions to another reply.
Actually, in AzureADPreview powershell module, there is a parameter -PreAuthorizedApplications for Set-AzureADApplication. But neither the cmdlet help nor the documentation page has been updated to detail all these, it was also mentioned here.
I am not sure the parameter will work or not, per my test, I always get a bad request error. Even if I call the Azure AD Graph API, I get the same error. The command Set-AzureADApplication essentially calls the Azure AD Graph API, so if the parameter works, it will also work for the API. Also, in the AAD Graph doc, there is no such property. According to the test result, the parameter seems not to work currently. (not sure, if there is something wrong, please correct me)
I got this error too using client_credentials type to get access_token to call that API even though I granted all Microsoft Graph API and AAD API application related permissions. It is really weird.
However , using password flow to get access token under Azure AD admin account will be able to call this API successfully :
Update
You could get your client id and client secret by below steps
Go to azure portal on azure active directory menu see the screen
hot below:
Once you select azure active directory you would see App
registrations click on that. Then select your application. See the below picture
On your apllication you would see the client id, tenant id and
client secret which marked on the screen shot below:
If you still have any concern please feel free to share. Thank you and happy coding!
to resolve token issue I did like this(if you have az subscription owner, in this case you can get token which allows to update aad owned application properties without aad admin login and password). After az login by subscription owner:
$msGraphAccess = az account get-access-token --resource "https://graph.microsoft.com |
ConvertFrom-Json
$accessToken = $msGraphAccess.accessToken
$headers = New-Object 'System.Collections.Generic.Dictionary[String,String]'
$headers.Add("Content-Type", "application/json")
$headers.Add("Authorization", "Bearer " + $accessToken)

How to get the access token to start or shut down VMs on azure classic portal?

How to get the access token to start or shut down VMs on azure classic portal, I have tried multiple links for the same such as https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-api-authentication, also whatever access token I m getting using that I can only start, shutdown ARM vms, not classic VMs. Can somebody please help me on this ?
I'm very lazy, so I'm using arm token to startup\shutdown classic vms :). sample code:
$header = #{ Authorization = "Bearer $token" }
$uri = "https://management.azure.com{0}/{1}?api-version={2}" -f $vmId, $action, $apiVer
Invoke-WebRequest -Headers $header -Method Post -Uri $uri -UseBasicParsing
to start use $action = 'start'
to shutdown use $action = 'shutdown'
for apiVersion use $apiVer = '2017-04-01'
for ID, just use classic VM resource id, example:
/subscriptions/GUID/resourceGroups/rgName/providers/Microsoft.ClassicCompute/virtualMachines/vmName
you would need to grant yourself (or the entity you are getting script on behalf of) proper rights. I'm using these:
"Microsoft.ClassicCompute/virtualMachines/read"
"Microsoft.ClassicCompute/virtualMachines/start/action"
"Microsoft.ClassicCompute/virtualMachines/shutdown/action"
"Microsoft.ClassicCompute/virtualMachines/operationStatuses/read"

Resources