I need to create a service connection in Azure DevOps for service type "Azure Resource Manager".
When I am trying "Service principal (automatic)", I am able to do with proper permission. But when I am trying "Service principal (manual)", it needs service principle key. May I know how to create it from Azure Portal?
Yes, as mentioned by #juunas, the service principle key is also named client secret, you can create it in your App Registration -> Certificates & secrets in the portal, follow this link.
For the Forbidden error, it means your service principal does not have the correct RBAC role in your subscription, just navigate to your subscription in the portal -> add an RBAC role e.g. Contributor for your service principal like below, details here.
Related
I currently create a service principal using the Azure CLI:
az ad sp create-for-rbac --name foo --role Contributor
I need the service principal to have enough permissions to create/modify/delete various Azure AD resources including Applications, other Service Principals and Service Principal Passwords. When I use the above service principal to create other service principals, I currently get 403 Forbidden errors.
I have also tried using the 'Owner' and 'User Access Administrator' roles but these still give me a 403 error. What do I need to add to the above Azure CLI command or what additional role assignments do I need to add?
I'd like to use the service principal in a Pulumi program with their Azure AD provider (based on Terraform's Azure AD provider). See:
https://github.com/pulumi/pulumi-azuread/issues/246
In order for a service principal to be able to manage applications it requires API permissions. There is no such thing as a scope, because the API permissions are against the Azure AD API. Scopes are only applicable when it is related to the Resource Manager API. These are not the same thing.
When you go to application registrations in Azure AD, you can find the application, this is also where you will be able to assign the API permissions and grant consent.
You will do this either on the Azure Active Directory Graph, or on the Microsoft Graph. In my experience only the permissions assigned with the Azure Active Directory Graph worked.
Application.ReadWrite.All
Application
Read and write all applications
Application.ReadWrite.OwnedBy
Application
Manage apps that this app creates or owns
You will find these two application permissions that you could use. The first you can use manage all applications.
The az cli command you are using is to create a role assignment. This is RBAC on the subscription, it has nothing to do with Azure AD aside from the service principal being an AAD resource.
You need to add the scope of this service principal and also change the Azure role of this Service Principal to 'User Access Administrator' to enable you to modify resources in Azure AD. Also, 'User Access Administrator' role will give the service principal the required permissions for that Azure role to assign RBAC permissions. Please refer the below command for more details: -
az ad sp create-for-rbac --name foo --role User Access Administrator --scopes /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup1}
Also, ensure that the user ID through which you are creating this service principal and assigning the role to it has permissions to register and create applications in Azure AD. If not, then please assign that ID 'Application Administrator' Azure AD role or you should be allowed to create and register applications by an administrator even though being a 'User'.
You need to give your service principal "App admin" permissions. This allows you to create application registrations and also set their credentials. And it does not give it rights to do anything else such as manage users and groups. If your intent is to include those, you need to add additional roles to the service principal.
https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#application-administrator
I have a python script running on an Ubuntu Linux virtual machine that needs to access a KeyVault in Azure. If have configured the following environment variables based on an "App Registration".
AZURE_CLIENT_ID=<Client ID from App Registration>
AZURE_TENANT_ID=<Tenent ID from App Registration>
AZURE_CLIENT_SECRET=<SECRET Created in App Registration>
When I try accessing the KeyVault I get an access denied error.
Code: Forbidden
Message: The user, group or application 'appid=<APP_ID>;oid=
<GUID_VALUE>;iss=https://sts.windows.net/<GUID_VALUE>/' does not have secrets get permission
on key vault '<KEY_VAULT_NAME>;location=westus'. For help resolving this issue, please see
https://go.microsoft.com/fwlink/?linkid=2125287
Inner error: {
"code": "AccessDenied"
}
I assume I am getting this, because there is no Role Assignment in the KeyVault, however I may be wrong.
When I try adding a new Role Assignment to the KeyVault, there is no option under "Assign access to" for "App Registration". I tried both "User, Group or Service Principal" and "User Assigned Managed Identity", but it I always get the error "No users, groups, or service principals found.".
What am I missing here?
What am I missing here?
There are a few issues here:
You're trying to assign an RBAC role to an App Registration. What you need to do is assign an RBAC role to the Service Principal. To get the Service Principal Id, you would need to go to Enterprise Applications section in Azure AD and find the Id of your Service Principal (Object ID).
Assigning Reader RBAC role will not do the trick as this role is for managing the Key Vault itself and not the data inside it. There are two ways to solve this:
Use Access Policies: You can define appropriate access policies in your Azure Key Vault to give access to keys, secrets and certificates to your Service Principal.
Use Data RBAC Roles: Instead of using Management RBAC roles (like Reader, Contributor etc.), you will need to use RBAC roles for managing data inside the Key Vault.
Please see this link for more details: https://learn.microsoft.com/en-us/azure/key-vault/general/assign-access-policy-portal.
I'm trying to create subscriptions through an Azure DevOps pipeline on a hosted agent running as a service principal and am receiving the error:
New-AzSubscriptionAlias: /home/vsts/work/1/s/Azure.Automation/Subscriptions/Create-AzureSubscription.ps1:190
Line |
190 | $subscription = New-AzSubscriptionAlias `
| ~~~~~~~~~~~~~~~~~~~~~~~~~
| Operation returned an invalid status code 'Unauthorized'
How do I grant the service principal the required access?
As it is written here in Programmatically create Azure subscriptions with the latest APIs
You must have an Owner role on an Enrollment Account to create a subscription. There are two ways to get the role:
The Enterprise Administrator of your enrollment can make you an Account Owner (sign in required) which makes you an Owner of the Enrollment Account.
An existing Owner of the Enrollment Account can grant you access. Similarly, to use a service principal to create an EA subscription, you must grant that service principal the ability to create subscriptions.
If you need to use a service principal to create a subscription, then you must grant the service principal the Azure RBAC owner role.
You can use the New-AzRoleAssignment command to assign the owner role to your service principal.
To specify a user, use SignInName or Azure AD ObjectId parameters.
To specify a security group, use Azure AD ObjectId parameter. And to specify an Azure AD application, use ApplicationId or ObjectId parameters. The role that is being assigned must be specified using the RoleDefinitionName parameter.
You need to use AzureRmRoleAssignment cmdlet to assign that service principal an Owner role.
We tracked it down to two missing permissions required by the underlying New-AzureRmRoleAssignment cmdlet that is called by the task -
The Service Principal (SPN) used by Azure DevOps to connect to your
Azure subscription requires the Owner role
The same SPN also requires Read directory data permissions to your
Azure AD
There is also a 3rd-party Azure Role Based Access Control task you could use in your azure devops pipeline.
More step by step tutorial, please refer this blog-- Service Principal considerations when using Azure DevOps to manage RBAC on Azure Resource Groups
When using Azure Key Vault management REST API or cmdlet Add-AzureRmKeyVaultNetworkRule to allow a virtual network to access a key vault, I get the following error:
The client '{guid}' with object id '{guid}' does not have authorization to perform
action 'microsoft.network/virtualnetworks/taggedTrafficConsumers/validate/action'
over scope '/subscriptions/{guid}/resourcegroups/{resource-group}/providers/microsoft.network/virtualnetworks/{vnet-name}/taggedTrafficConsumers/Microsoft.KeyVault'
What is wrong?
Your subscription is not giving Microsoft.KeyVault resource provider permission to access Microsoft.Network resources. The fix is to register your subscription to Microsoft.KeyVault again:
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.KeyVault
This will add required permissions for Microsoft.KeyVault and Microsoft.Network integrations, including the ability to limit access to a given Virtual Network.
For more information: https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-supported-services
This are the steps required to solve it:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/resource-providers-and-types#azure-portal
You just need to register the resource provider in the subscription, this doesn't only happens with Key Vault, my issue was with Sql Server as well :)
So I leave this answer here in case someone else needs it
This feels like a bug/limitation in both the Azure Portal and Azure CLI. We ran into this when trying to allow a subnet of a VNET in subscription X to access a storage account in subscription Y.
For us, the workaround was to look-up the name of the service principal that was mentioned in the error in our Azure AD directory using the "Search your tenant" box on the "Overview" tab of the directory (NOT the subscription but the Azure AD directory for the tenant). The name of the SP turned out to be "Storage Resource Provider" (yours may be different, so that's why you need to look it up in Azure AD), so we granted that SP "Owner" role (temporarily) in the other subscription. Then provisioning worked!
There should be a finer-grained set of permissions you need to grant than just "Owner" but when we granted just the "validate" permission, we got a new error:
Failed to save firewall and virtual network settings for storage account 'XXX'. Error: An operation is currently performing on this storage account that requires exclusive access.
Also experienced this error when adding a vnet to a storage-account in another subscription.
Fixed by adding a storage-account to the subscription using the portal. Then the vnet could be added to the storage-account.
Note: the result is the same as #fernacolo does with a powershell command.
Three topics in Azure AD I'm constantly confused on:
Service Principal
Enterprise Application
App Registration
What is the difference?
I can easily go into "App Registrations" and register an "app" while that "app" doesn't even need to exist. All it requires is a URL which can also be totally random. This app registration then becomes a service principal which you can use to connect to Azure to from PowerShell for instance? Why? I don't understand this.
Please advise, and as you can probably tell, I'm new to Azure :)
When you write an application as a developer, you will register it in a given tenant, and will specify it's properties. This happens in the App Registration blade in Azure AD.
I'll dare an analogy by saying that the app is like a "class" in object oriented languages (with some static properties, which will be common to all instances)
By registering the application, in that given tenant if you use the portal this also automatically created a service principal for this application, which you can find in the "Enterprise Applications" blade of the Azure portal.
To continue with my analogy the portal creates a kind of instance of that class. This service principal contains information which are related to both the application and the tenants and its users. For instance it contain the activity of the users, what they have consented to in particular.
Now if during the app registration / app management, you decide that your application is "multi-tenant", then, when the application is accessed in other tenants, another service principal (remember this instance) will be created in that tenant.
BTW, you go to the new App Registration (Preview) blade in the azure portal, when you create an application, you can now see nicely grouped by categories all the properties of the app (all the properties which are common to all the service principal). Now if, in the "Overview" tab of the app, you click on the link "Managed application in local directory", you'll get to the corresponding service principal in the same tenant (where you'll see which users have accessed the app, when, where you can grant admin consent - if you are tenant admin -, and see the activity and the audit logs)
This is indeed confusing, and you are not the only one who feel that way. I guess this whole application/service principal is designed from the perspective of web applications, which can be scaled across multiple Azure AD tenants. For someone, who just wants to create some small scripts which connects to Azure services, understanding this whole thing is too much. Unfortunately there is no way around it. Azure Portal is also little bit confusing for this part, it only started to make some sense when I used Azure CLI for it.
To access Azure resources programmatically, we need to use Service Principal credentials. Service Principal is actually an instance of application, so we need to create an Application(App Registration) first too. If App Registration is added from portal, Service Principal is created automatically. With Azure CLI creating Application and Service Principal are two distinct steps.
Tricky part is, credentials has to be obtained from Application(App Registrations -> select app -> Certificates & Secrets). While the role assignment for the Service Principal has to be done from Subscriptions(select subscription -> Access control(IAM) -> Role Assignments) or any other resource which supports IAM. Same process using CLI makes more sense.
Using Azure CLI
Register/create app
$ az ad app create --display-name "displayName"
Create service principal for the app just created
$ az ad sp create --id "applicationId"
Set application credentials
$ az ad app credential reset --credential-description "some_description" --id "applicationId"
OR
$ az ad sp credential reset --credential-description "some_description" --name "applicationDisplayName" --append
Assign roles to Service Principal to access resources in Azure.
$ az role assignment create --assignee "service principal object id/ApplicationId" --role role_name
And if you don't care about all this application/service principal stuff and just want to use Service Principal for accessing Azure resources, there is a shortcut.
$ az ad sp create-for-rbac --name "service_principal_name"
This will create application, service principal, set credentials on app, assign Contributor role at subscription scope to service principal and print the credentials !!
Since the name of the Application(in App Registrations) and Service Principal(Enterprise/All Applications) is same, we need to look carefully at Object ID and Application ID to find out which is which. On the top of that, Service Principals are listed as Enterprise Applications/All Applications in Azure Portal.
'Enterprise Applications' is just a category of Service Principal which satisfies two conditions.
Service Principal and Application registration should be in same tenant.
Service Principal should have tag 'WindowsAzureActiveDirectoryIntegratedApp'. If this tag is removed from Service Principal, it won't show under Enterprise Applications, but still be listed under 'All Applications'. ( Do not try in production!! )
Note that service principals created from cli did not appear in 'Enterprise Applications' and I had to add the tag manually.
$ az ad sp update --id "service_principal_object_id" --add tags WindowsAzureActiveDirectoryIntegratedApp