I registered an app registration via Register-PnPAzureADApp which has application level Sites.FullControl.All permissions and an admin has consented to it too.
I then connected using this App Registration: Connect-PnPOnline -ClientId xxx -Url https://tenant.sharepoint.com" -Tenant tenant.onmicrosoft.com -CertificatePath 'path\to\cert.pfx. This too succeeds.
My end goal is to have another app registration with Sites.Selected permissions so I can limit it to specific sites. Before doing that if I were to try and look at the existing permissions of a site via Get-PnPAzureADAppSitePermission -Site https://tenant.sharepoint.com/sites/sitename it errors:
Get-PnPAzureADAppSitePermission: {"error":{"code":"accessDenied","message":"Access denied",...
Same deal if I try and set permissions too via Grant-PnPAzureADAppSitePermission.
Am I missing something here?
Thanks,
Rakhesh
Based on the Get-PnPAzureADAppSitePermission document, the required permission is Microsoft Graph API: Sites.FullControl.All rather than SharePoint permission.
So you should add this permission in AAD app.
Related
I have created PowerShell 7 Azure Function (AF) and a managed service identity (MSI) with reader role across the entire subscription.
Using this code here:
Connect-AzAccount -Identity
$token = Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com"
Connect-MgGraph -AccessToken $token.Token
The connection, via Graph works as I receive the 'Hello to Graph' in the (AF) log window.
However, when searching for a user;
get-mgUser -userID 'objectID of the user'
I receive permission denied.
Using:
connect-mgGraph -Scopes
Prompts for an interactive login...
Looking at the Enterprise application registration for the MSI, I'm unable to grant any permissions (logged in as GA).
Can someone point me in the right direction please?
The error "permission denied" usually occurs if there are no required permissions to perform the action.
I agree with Cpt.Whale that at least User.Read.All is required.
To grant the API permissions to an Enterprise Application, make sure that the application is present in Azure AD.
Locate your Enterprise application in Azure Ad like below:
Go to Azure Portal -> App Registrations -> Select App with your Enterprise Application name -> API permissions
After adding the permissions and granting admin consent, the API permissions will be successfully added in your Enterprise application like below:
To know more in detail, please refer below links:
Give permissions to graph api in enterprise application Azure AD by Hury Shen
Configure required Azure AD Graph permissions for an app registration - Microsoft Graph | Microsoft Docs
We have an Azure PowerShell script to automate the provisioning of resources in our customers' subscription. As part of the process we deploy a VM based off a custom image hosted in our own image gallery. In order to do so we require our customers to grant access (user consent) to our enterprise application in their tenants.
As of now we achieve that through an OAuth2 link that we ask them to edit with their own tenant ID and open in browser:
https://login.microsoftonline.com/<customer-tenant-id>/oauth2/authorize?client_id=cd3df191-153a-4ae1-9766-5fe7a7f3032e&response_type=code&redirect_uri=https%3A%2F%2Fwww.microsoft.com
This link authenticates them and asks for the requested permissions to be accepted:
After that, our enterprise application should be listed in their subscriptions with the following permissions:
We would like for this pre-requisite to be addressed programmatically by our deployment script. Is there any way we can achieve that via Azure PowerShell?
To no avail, I've checked quite a few pages online and several similar questions here on SO. They are different in the sense that they are requesting Admin Consent rather than User Consent (mind that ours only require User Consent, see screenshot below). Also, some questions are specific to Azure CLI or simply Azure Portal (not an option for us as we are working with Azure PowerShell).
PS: Sorry in advance for my lack of knowledge in regards to Azure AD and the Consent Framework in general.
Consent can be used to grant app roles (application permissions) and delegated permissions.
What you're trying to do here is to create a delegated permission grant. Specifically, you're trying to grant a delegated permission on behalf of an individual user (instead of on behalf of all users).
You can't do this with Azure PowerShell.
You can, however, do this with Microsoft Graph PowerShell. The cmdlet you use, will be New-MgOauth2PermissionGrant. This cmdlet calls the Microsoft Graph API to create a delegated permission grant. The PowerShell cmdlet requires the following parameters:
ClientId - The object ID of the client app's service principal. This is the service principal which will be gaining privileges.
ConsentType - In this case, this should be "Principal", indicating you want to grant this delegated permission on behalf of a single principal (a user).
PrincipalId - This is the object ID of the user on behalf of who the client app will be able to act.
ResourceId - The object ID of the API's service principal. This is the service principal representing the API that exposes the delegated permissions you want to grant.
Scope - The space-separated list of permissions to grant.
So, for example, if we wanted to grant the Microsoft Graph delegated permission User.Read, on behalf of user with user principal name bob#example.com, we could do the following:
$userUpn = "bob#example.com"
$clientAppId = "738a2731-dd81-4263-824b-74cf6dee9da0"
$resourceSpn = "https://graph.microsoft.com"
$scope = "User.Read"
# Retrieve the user, and the client and resource service principals
$user = Get-MgUser -Filter "userPrincipalName eq '$userUpn'"
$client = Get-MgServicePrincipal -Filter "appId eq '$clientAppId'"
$resource = Get-MgServicePrincipal -Filter "servicePrincipalNames/any(n:n eq '$resourceSpn')"
# Grant the delegated permissions for Microsoft Graph to the client, on behalf of the user
$grant = New-MgOAuth2PermissionGrant `
-ClientId $client.Id `
-ConsentType "Principal" `
-PrincipalId $user.Id `
-ResourceId $resource.Id `
-Scope $scope
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.
Now I have one App in Azure active directory1, and a web api in Azure active directory2. My aim is to allow users in AAD1 and AAD2 can both login the App.
So far I've enabled App and Api as multi-tenant, added each other in the manifest as known client application.
The things I've not finished yet: add one as a custom domain into the other, add permissions btw api and app, and I met some problems on these two.
Right now my error msg is:
An error has occurred while authorizing access via Authorization Server: unauthorized_client AADSTS65005: Invalid > resource. The client has requested access to a resource which is not listed in the requested permissions in the client's application registration.
When I tried to give the access in the api, in the required permission list, I didn't see the web app (which is in the other directory). How should I do with it?
If I move both App and Api under the same directory, is there anyway that allows users from the other directory to login?
In order for you to see the Web API in Tenant 1 as an option for "Required Permission List", you need to provision the service principal for the Web API into Tenant 1.
You can do this a number of ways, but the easiest way may be to simply sign into the Web API by generating a Login URL. Once you login, using a user from Tenant 1, the service principal will be provisioned in the tenant, and then be an option available to select.
https://login.microsoftonline.com/common/oauth2/authorize?client_id=<appid>&response_type=code&redirect_uri=<replyurl>&resource=<resource>&prompt=consent
The other option might be to use AAD PowerShell to create a service principal based off your Web API App Id:
New-AzureADServicePrincipal
New-AzureADServicePrincipal -AccountEnabled $true -AppId $MyApp.AppId -DisplayName $App -Tags {WindowsAzureActiveDirectoryIntegratedApp}
Once you have successfully put the service principal on your required permissions, the error message you described above should go away.
In addition to Shawn Tabrizi's answer, you can also specify your API as a known client application of the App.
So in your App's manifest:
"knownClientApplications": [
"your-api-client-id"
]
Then if you try to authenticate to the App, it can do consent for the API as well at the same time.
So I am trying to set up an application on azure AD that can, among other things delete users.
I have the application registered and use the client id and secert to gain teh access token.
I was able to give the application permissions to create users and that works fine, but when i go to delete over the graph API i get a 403 Insufficient privileges to complete the operation.
I am trying this over the graph rest API. The user that i am attempting to delete was made through the rest call as well. The user is in the same tenant as the application , so i am not trying to delete users from multiple tenants.
It seems what i need to do is give the application either Global admin or Company admin rights, but i am spinning wheels on where and or how to do this.
Any help would be appreciated.
Take a look at my answer here.
You can elevate the level of access an Application has in your tenant
by adding the service principal of that application to the Company Administrator Directory Role. This will give the Application the same
level of permissions as the Company Administrator, who can do
anything. You can follow these same instructions for any type of
Directory Role depending on the level of access you want to give to
this application.
Note that this will only affect the access your app has in your tenant.
Also you must already be a Company Administrator of the tenant to follow these instructions.
In order to make the change, you will need to install the Azure
Active Directory PowerShell
Module.
Once you have the module installed, authenticate to your tenant with
your Administrator Account:
Connect-MSOLService
Then we need to get the Object ID of both the Service Principal we
want to elevate, and the Company Administrator Role for your tenant.
Search for Service Principal by App ID GUID:
$sp = Get-MsolServicePrincipal -AppPrincipalId <App ID GUID>
Search for Directory Role by Name
$role = Get-MsolRole -RoleName "Company Administrator"
Now we can use the Add-MsolRoleMember command to add this role to
the service principal.
Add-MsolRoleMember -RoleObjectId $role.ObjectId -RoleMemberType ServicePrincipal -RoleMemberObjectId $sp.ObjectId
To check everything is working, lets get back all the members of the
Company Administrator role:
Get-MsolRoleMember -RoleObjectId $role.ObjectId
You should see your application in that list, where RoleMemberType
is ServicePrincipal and DisplayName is the name of your
application.
Now your application should be able to perform any Graph API calls
that the Company Administrator could do, all without a user signed-in,
using the Client Credential Flow.
Let me know if this helps!
UPDATE:
The answer above has been updated to use Azure Active Directory V2 PowerShell
If you don't have the AzureAD module already installed you will need to install it. See Azure Active Directory PowerShell Module Version for Graph for Azure AD administrative tasks for more info about the module or simply run:
Install-Module AzureAD
Once you have the module installed, authenticate to your tenant with your Administrator Account:
Connect-AzureAD
Then we need to get the Service Principal we want to elevate, and the Company Administrator Role for your tenant.
$sp = Get-AzureRmADServicePrincipal | Where DisplayName -eq '<service-principal-name>'
Search for Directory Role by Name
$role = Get-AzureADDirectoryRole | Where DisplayName -eq 'Company Administrator'
Now we can use the Add-AzureADDirectoryRoleMember command to add this role to the service principal.
Add-AzureADDirectoryRoleMember -ObjectId $role.ObjectId -RefObjectId $sp.Id
To check everything is working, lets get back all the members of the Company Administrator role:
Get-AzureADDirectoryRoleMember -ObjectId $role.ObjectId
You should see your application in that list, where DisplayName is the name of your application.
Now your application should be able to perform any Graph API calls that the Company Administrator could do, all without a user signed-in, using the Client Credential Flow.