I'm working with an app registration that has a secret defined. Via PowerShell I am able to get the credential, but not the secret value. Function used is Get-AzADAppCredential This is expected behavior, no issue here.
To renew the secret I run two functions Remove-AzADAppCredential and New-AzADAppCredential.
I run these PowerShell cmdlets via a DevOps pipeline and use a service connection with permissions in Azure portal.
I noticed that, when we create a service connection from DevOps to Azure, the service principal gets the role Cloud application administrator automatically assigned.
This role includes the permission "microsoft.directory/applications/credentials/update".
So the above (remove + new) should work, but it does not...
DevOps returns an error:
Az.MSGraph.internal\Remove-AzADApplicationPassword : Insufficient privileges to complete the operation.
Az.MSGraph.internal\Add-AzADApplicationPassword : Insufficient privileges to complete the operation.
PS. Using Az.Resources version 5.4.0 when working with the PowerShell functions.
Anyone got any idea what I'm missing?
Thanks.
Insufficient privileges to complete the operation.
The error comes when the user doesn't have sufficient privileges in AAD and doesn't have Write permission for the selected Azure Subscription.
Note: If you have Cloud application administrator privileges of the user, this role grants the ability to manage application credentials. Users assigned this role can add credentials to an application and use those credentials to impersonate the application’s identity. If the application’s identity has been granted access to a resource, such as the ability to create or update User or other objects, then a user assigned to this role could perform those actions while impersonating the application.
Make sure to check once if you have Global Administrator Access. If you have the access you can able to Modify the secret.
Users who are assigned to the Global administrator role can read and modify every administrative setting in your Azure AD organization.
The permission issue may happen due to
The user has only guest permission in the directory
The user is not authorized to the add applications in the directory
Refer here for detailed information
To be able to update a secret on an app registration, through DevOps, using a service principal, with minimal permissions, first make the service connection owner on that random app registration.
Next, add the Application.ReadWrite.OwnedBy application API permission on the app registration that's linked to the enterprise application. Not on the app registration where the service principal was made owner.
Than renewing the secret works fine.
It remains a question though why the role Cloud application administrator isn't sufficient because microsoft.directory/applications/credentials/update is included in that role, and that should also be enough.
Related
From the page about Azure CLI Sign-in:
Service principals are accounts not tied to any particular user, which can have permissions on them assigned through pre-defined roles. Authenticating with a service principal is the best way to write secure scripts or programs, allowing you to apply both permissions restrictions and locally stored static credential information
It seems that a service principal is kind of a service account, a sort of identity which isn't tied to any specific person.
On the other hand, from here it seems that a service principal is an instantiation of the Application object in the domain of App registrations. This has something to do with registering an application so it can be authorized using OAuth 2.0 etc. etc.
So I can't understand the relation between these two concepts. Can someone help?
Service principal is sort of a service account.
It is the thing that permissions are assigned to.
For example, if you consent to an application reading your user profile on your behalf, that adds an OAuth 2 permission grant to the service principal.
Application permissions add an app role assignment to the service principal when granted.
When you make an app registration, a service principal is also created in that same Azure AD tenant.
Even though you add required permissions and consent to them through the app registration forms, the permissions are actually assigned to the service principal.
The app registration is only really a template.
Where this gets interesting is if you have a multi-tenant app (other Azure AD tenants' users can use your app).
In this case a service principal representing your app is also created in other Azure AD tenants when a user consents to the permissions your app requires.
Essentially you get an automatically generated service account in each tenant using your app.
This allows admins to decide which permissions to grant your app, which users can access the app etc.
I've registered a single application in Azure AD for the following reasons.
Azure AD SSO (From Any Azure AD directory)
Read users, groups, and their members
Provided following permissions and granted admin consent.
NOTE: We still depend on some of the Azure AD Graph API. So, we have added the legacy API permissions.
I can able to contact the Azure AD using REST API and get the user, groups and other information.
When I try to sign in to the application from any other directory, I'm getting the following consent screen. I can able to provide the consent and proceed to log in.
But, when I try to login into the same directory, I'm not getting the consent screen even when I logged in with the Azure AD admin. Stuck in the following screen.
When I register separate applications for SSO and REST APIs, this issue doesn't occur.
I would like to know why I'm stuck in the above screen when combining both SSO and REST API permissions.
• Please check whether the correct Azure AD roles have been assigned to your account ID, i.e., Global Administrator, Cloud Application Administrator, Application Administrator, or owner of the app object through the as one of these is needed for you to access the application. Also, ensure that you have assigned your account ID the correct app role assignment for the admin consent to be allowed during the SSO signup process as below: -
You can check the app role assignments for your account ID through the Enterprise application blade and searching your application there, then opening it and selecting the users and groups blade, check the app role assignment that your account ID has to that application while also, giving ‘Azure Service Management’ api permissions for user_impersonification as below, thus ensuring that you account ID will be having correct API permissions.
Once, the above settings are configured correctly, you should be able to access the application through your admin credentials.
I need to register an application in Azure AD using PowerShell. I plan to use the New-AzADApplication cmdlet. The cmdlet documentation states the following:
Below are the permissions needed to create an application:
Azure Active Directory Graph
Application.ReadWrite.OwnedBy
Microsoft Graph
Directory.AccessAsUser.All
Directory.ReadWrite.All
I've learned that these permissions are scopes, which is a new concept to me and something I don't know how to deal with in Azure. I found this short demo, which shows these scopes can be managed as API permissions from the Azure App registration context. However, that demo shows the scopes being managed after the application has already been created. How can I establish the proper scopes before the application is created?
Or, more generally, how can I ensure that I have the appropriate permissions to execute the New-AzADApplication cmdlet?
The application that needs those permissions is Azure AD PowerShell in this case. If it didn't have a service principal in your AAD tenant yet, you would be asked for consent to those scopes on first login when using the Connect-AzureAD cmdlet.
In my experience, the service principal that it uses already exists in your tenant. So it already has the needed permissions. But what will also matter is your user permissions. Since it uses delegated permissions, it is acting on behalf of your user. In order for it to be able to create the app, it needs to have the necessary scope/delegated permission and your user must be able to create applications.
The cmdlets do also support acting as a service principal/app, in which case application permissions given to the app used to authenticate would apply, not delegated permissions. But that's another case that I don't think you are asking about.
Applications are able to note which permissions they require (both delegated and application) in the app registration portal. This allows use of the /.default scope and the Azure portal's "Grant admin consent" option.
You can follow this process:
1.Go to your application in the Azure portal – App registrations experience, or create an app if you haven't already.
2.Locate the API Permissions section, and within the API permissions
click Add a permission.
3.Select Microsoft Graph from the list of available APIs and then add
the permissions that your app requires.
4.Save the app registration.
I am working with an organization that has disabled user consent for azure apps.
"Users can consent to apps accessing company data on their behalf" is set to No in the Azure Portal.
I would like developers to be able to give consent to they own apps in azure without setting the above setting to yes. (the apps needs the "Sign in and read user profile" delegated permissions Azure AD).
1: Is it correct that the only other way is the assign the developers to one of the Azure AD roles that has one of these permissions: Application Developer, Application Administrator or Cloud Application Administrator?
2: I would also like to automate this process during a AzureDevOps release pineline. Currently the release pipeline creates all needed Azure resources via ARM Templates.
But how do I automate the App Registration without going to the Portal?
And how do I ensure that the release pipeline has the correct Azure AD permission to give consent?
Can I force the Pipeline to run as an "Azure AD Service User that I give the above role?
Update 1
It seems that its possible to do Azure AD Registration with powershell. http://blog.octavie.nl/index.php/2017/09/13/creating-azure-ad-app-registration-with-powershell-part-1
Since the AzureAD is using MFA, the script will display an interactive credential dialog when running. Not sure if we can suppress that.
Update 2
And give app consent with powershell. https://www.mavention.nl/blogs-cat/create-azure-ad-app-registration-with-powershell-part-2/?cn-reloaded=1
Update 3
So to automate the whole process, I was thinking if we could use a Azure DevOps Service Connection to execute these powershell scripts during the release pipeline?
Not sure what permission is needed for the Azure DevOps Service Connection?
It should also suppress the MFA credential dialog.
Is it correct that the only other way is the assign the developers to one of the Azure AD roles that has this permission: Application Developer, Application Administrator or Cloud Application Administrator?
It depends on the permissions the app is requesting, and who you would like the developers to be consenting for (themselves, or the entire organization):
Members of the Application Developer directory role can consent only to delegated permissions (not application permissions), and only on behalf of themselves (not on behalf of the entire tenant). Only other members of this role would be able to use the app (they would each consent on behalf of themselves), and only if the permissions requested are user-consentable delegated permissions. If your only requirement is for developers to be able to get delegated User.Read permission to Microsoft Graph, then this would work.
Members of the Application Administrator and Cloud Application Administrator directory roles can consent on behalf of all users for both delegated permissions and app-only permissions, except for app-only permissions to Azure AD or Microsoft Graph. These roles are both very privileged, and it is unlikely you would want the average developer to posses this--certainly not if the only permission needed is delegated User.Read.
But how do I automate the App Registration without going to the Portal?
With the Microsoft Graph API, you can register an app by creating an Application object. As of 2018-12-05, this is still in beta in Microsoft Graph.
If you require a production-ready endpoint, the Azure AD Graph API supports this, which is what's used by the various command-line and PowerShell options: New-AzureADApplication, az ad app create, and New-AzureRmADApplication.
To do this without a user involved, the client application (the one creating the app registration) requires the Application.ReadWrite.OwnedBy application permission, at minimum.
And how do I ensure that the release pipeline has the correct Azure AD permission to give consent?
This is where things get complicated. While it is possible to create the app registration (the Application object) as described above, these is currently no application permission that would allow an app to grant consent for another app. Though there is work underway to allow for "normal" application permissions to allow one app to grant other apps some permissions, currently only members of the directory roles authorized to consent to these permissions are able to perform this action.
I'm trying to fetch users from azure active directory using graph api. I've tried many ways, none of them worked, but let's stick to simplest one - using this instruction and some app to make http requests (I'm using postman) I'm able to obtain autherization token with no problem. After that I want to get users list using https://graph.microsoft.com/v1.0/users, passing token in header. Instead of the users list I get "Insufficient privileges to complete the operation." This error message is very confusing to me because app registration has now all possible permissions and service account that owns this app is in role of Global Administrator, so I believe there aren't any more privileges that this app could get.
Task of the application I'm developing is to merge users data from few companies and display users list on web page hosted on azure account of one of them. What's even weirder for me in all of this, is that for one these domains accesing users data using graph api actually works, so logically configuration isn't set correctly everywhere, but I don't really know what can be difference that makes one them work and others fail on "Insufficent privileges error".
As you are integrating AAD in app only applications, as the description at https://graph.microsoft.io/en-us/docs/authorization/app_only:
After you register the application, configure the application permissions that your service or daemon app requires.
So, firstly, you may check out whether you have configured the correct permission on Azure portal:
According to your error message:
Insufficient privileges to complete the operation
And the application permissions require that your application has admin privileges. You can try to upgrade the role of the AD application you use to a administrator permission. Run the following commands in PowerShell:
Connect-MsolService
$ClientIdWebApp = '{your_AD_application_client_id}'
$webApp = Get-MsolServicePrincipal –AppPrincipalId $ClientIdWebApp
#use Add-MsolRoleMember to add it to "Company Administrator" role).
Add-MsolRoleMember -RoleName "Company Administrator" -RoleMemberType ServicePrincipal -RoleMemberObjectId $webApp.ObjectId