I added a Personal Tab in MS Teams which references a SharePoint Webart with on it an SPFx webpart using #microsoft/microsoft-graph-client.
In the MS Teams Web Client on TEST and PROD the page loads as expected, and the #microsoft/microsoft-graph-client calls work.
In the MS Teams Desktop client on TEST environment also work perfect.
However, in the MS Teams Desktop Client (on windows) on PROD environment the #microsoft/microsoft-graph-client does not work.
Looking in Fiddler, I can see the following happening (only on the dekstop client):
A call is made to https://o2fitcom.sharepoint.com/_api/Microsoft.SharePoint.Internal.ClientSideComponent.Token.AcquireOBOToken?resource=%2758066c29-7a47-418b-9cb8-69adf68633b3%27&clientId=%2708e18876-6177-487e-b8b5-cf950c1e598c%27
with error result Failed to load resource: the server responded with a status of 403 ()
The call returns an HTTP 500 with message:
<m:error xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<m:code>-2147024891, System.UnauthorizedAccessException</m:code>
<m:message xml:lang="en-US">Attempted to perform an unauthorized operation.</m:message>
</m:error>
I already success make solution work on TEST but not in PROD, checked all the configuration and manifest are the same. All the configuration of permission in the SharePoint Online Client Extensibility Web Application Principal are granted.
Finally I have a solution that:
Delete the app SharePoint Online Client Extensibility Web Application Principal and SharePoint Online Client Extensibility Web Application Principal Helper
Wait few mins let the AAD create them again.
After that request permission from custom app.
Go to API access page to grand again the permission will automatically sync to "SharePoint Online Client Extensibility Web Application Principal".
Test again the app. Also deactivate the Limited-access user permission lockdown mode could be help. Now all my app work as expected.
Why?
Limited-access user permission lockdown mode could block your permission to request api.
Delete App in AAD to get the the token and all the configuration sync again.
The way to grand permission from API Access it correct not grant from AAD App.
Related
I've built a .net core 7 web application.
It implements windows authentication, and works nicely on premise.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme).AddNegotiate();
I've deployed to an azure app service, and I get got this error when I browse to the application:
InvalidOperationException: The Negotiate Authentication handler cannot
be used on a server that directly supports Windows Authentication.
Enable Windows Authentication for the server and the Negotiate
Authentication handler will defer to it.
So I added a Microsoft Azure AD identity provider, which created for me a new app registration. Now I can browse to the application, enter my credentials, but it once I do, I get another dialog saying "Approval required, enter justification". After I submit my request approval, I get an email saying my request was received. I don't know who gets the approval request, or why a request is being generated. We could have hundreds of employees using the application, and will eventually have dozens of applications, so an approval request might not be manageable. Can it be turned off, or am I implementing the authentication wrong in the first place?
Approval Request:
Email:
If you have the right premissions, you might be able to grant consent on behalf of all users yourself. This ensures that end users will not be required to consent when using the application. To do this, navigate to your App Registration Overview and click on 'Go to Enterprise applications'. From there, click on the Permissions in the left menu. At this page you can grant admin consent to all users.
These global settings can be changed, but only by an administrator. How you can do that is described in this article: https://intercom.help/eventtemple/en/articles/5152672-need-admin-approval-approval-required-when-connecting-outlook-office365
I created a blazor server app like this:
That works fine on my local machine. However, when deploying the website to azure I get the following error message: AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application
In the azure portal I navigated to the enterprise application that was automatically created during the project creation in visual studio. However, the "Homepage URL" is readonly.
How can I make this work?
Method 1:
Instead of Enterprise application go to App registration click on Authentication under Manage group, in Authentication Menu you can specify redirect URL.
Method 2:
You can modify application manifest for redirect URL and save it after modification.
Considering AAD application is created using your own account you should be owner of this application and can be able to modify it.
Let me know for any question, happy to help!
This question is very similar to a question which has been asked previously on StackOverflow. However, the error I'm getting is different.
AadHttpClient fails when loading SP page with SPFx webpart in MSTeams Desktop Client
I also have a Sharepoint Online site in which I have an SPFx web part which makes use of AadHttpClient.
This webpart works if I navigate to the Sharepoint site from a browser or open MS Teams web client.
A glimpse of my setup:
Here is a "steps to repro" overview of the issue I am facing.
Deploy the web part to SharePoint
View the web part in SharePoint – web part displays and loads OK
Add a SharePoint Tab in Teams and bind it to the page with the web part
View the tab in Teams Desktop client – data fails to load in web part (refer below)
View the tab in Teams Web client – web part displays and loads OK
When I debugged the MS Teams desktop client, I have this call in in the Network requests tab:
https://{mytenant}.sharepoint.com/sites/{mysite}/_api/Microsoft.SharePoint.Internal.ClientSideComponent.Token.AcquireOBOToken?resource={GUID of my AAD app registration}&clientId={GUID of SharePoint Online Client Extensibility AAD app registration}
With the response:
Error 403:
{"odata.error":{"code":"-2147024891,
System.UnauthorizedAccessException","message":{"lang":"en-US","value":"Access
denied. You do not have permission to perform this action or access
this resource."}}}
One interesting observation was that this web request only happens in Microsoft Teams desktop client.
I am interested in knowing why this only happens in MS Teams desktop client and not on either the MS Teams web client or Sharepoint Online.
Update: 10/02/2020
Another observation: We tried the same setup on a different tenant (personal tenant instead of our corporate tenant). We noticed that the same behaviour could be reproduced when MFA is turned-on on the Azure Active Directory.
The request that's failing is:
https://{personal tenant}.sharepoint.com/sites/{site name}/_api/Microsoft.SharePoint.Internal.ClientSideComponent.Token.AcquireOBOToken?resource={GUID of the AD app registration}&clientId={GUID of the SPO Client Extensibility app registration}
However, now the error returned is a 500 with the response:
{"odata.error":{"code":"-1,
System.AggregateException","message":{"lang":"en-US","value":"One or
more errors occurred."}}}
Similar issue found, (but a different error) out on Github: https://github.com/SharePoint/sp-dev-docs/issues/4915
I faced similar issue recently for a webpart that was calling graphAPI. On Desktop teams the call never use to happen and it use to get stuck. I was able to fix it by following these steps: -
Step 1. Visit the new API Permission Management Page on the Tenant Admin Site. This creates a client secret behind the scenes.
Step 2. Go to -> https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps
Step 3. Click on SharePoint Online Client Extensibility Web Application Principal
Step 4. Click Manifest on the left menu Step 5. Copy the id from the oAuth2Permission array
"oauth2Permissions": [
{
"adminConsentDescription": "Allow the application to access SharePoint Online Client Extensibility Web Application Principal on behalf of the signed-in user.",
"adminConsentDisplayName": "Access SharePoint Online Client Extensibility Web Application Principal",
"id": "2143704b-186b-4210-b555-d03aa61823cf",
"isEnabled": true,
"lang": null,
"origin": "Application",
"type": "User",
"userConsentDescription": "Allow the application to access SharePoint Online Client Extensibility Web Application Principal on your behalf.",
"userConsentDisplayName": "Access SharePoint Online Client Extensibility Web Application Principal",
"value": "user_impersonation"
}
],
Step 6. Replace “preAuthorizedApplications” entry with the following json. Keep the appId as it is written below.
"preAuthorizedApplications": [
{
"appId": "00000003-0000-0ff1-ce00-000000000000",
"permissionIds": [
"YOUR COPIED ID FROM STEP 5"
]
}
],
Step 7. Hit Save.
Let me know if this works for you. I referred the above steps from https://github.com/SharePoint/sp-dev-docs/issues/3923#issuecomment-514726341
Finally I have a solution that:
Delete the app SharePoint Online Client Extensibility Web Application Principal and SharePoint Online Client Extensibility Web Application Principal Helper
Wait few mins let the AAD create them again.
After that request permission from custom app.
Go to API access page to grand again the permission will automatically sync to "SharePoint Online Client Extensibility Web Application Principal".
Test again the app. Also deactivate the Limited-access user permission lockdown mode could be help.
Now all my app work as expected.
Why?
Limited-access user permission lockdown mode could block your permission to request api.
Delete App in AAD to get the the token and all the configuration sync again.
The way to grand permission from API Access it correct not grant from AAD App.
Is it possible to set up a single "Native app" which can be used by users on different Azure accounts/directories so they can get data from their Office 365 Sharepoint Online?
We can get this working using a "Web app" because in the Azure portal where you set this up it has the "Multi-tenanted" option which can be set to Yes - the notes for this support this:
Designates whether users in external organizations are allowed to
grant your app access to data in their organization's directory. This
control affects only the ability to grant access. It does not affect
any access that has already been granted.
And some early testing suggests this does indeed work. However this implies using an Oauth secret which must be embedded in the app and the notes here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code
State (in relation to the app secret):
....It should not be used in a native app, because client_secrets
cannot be reliably stored on devices. It is required for web apps and
web APIs, which have the ability to store the client_secret securely
on the server side.
For native apps, the docs here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview
State:
Native client registrations are multi-tenant by default. You don’t
need to take any action to make a native client application
registration multi-tenant.
Which suggests they should work in the way we desire - however when we test this with OAuth flow from an account not in the same Azure AD where the native app was setup we get the following after authenticating:
AADSTS70001: Application with identifier 'XXXXXXXXXXXXXXXXXXXXXX' was not found in the directory YYYYYYYYYYYYYYYYYYYY
So it appears this does not work. At present the only way it seems to make this work is to create a Web app and embed the client ID and secret in the native application.
Has anybody had success with multi-tenant native apps or any ideas/feedback on what I am doing wrong or could try?
UPDATE I realised there were two things wrong here:
* You can actually click on the "Manifest" button in Azure and edit the raw JSON, updating the 'availableToOtherTenants' value to make it multi-tenant.
* I didn't have the scope=user_impersonation in the OAuth flow.
Now it seems we can create a native app which users in other orgs/tenants can authenticate with.
UPDATE 2 OK so it turns out our app now works for some users but at least one is getting:
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. Client app ID: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA. Resource value from request: https://XXX.YYYYYY.com. Resource app ID: ZZZZZZZZZZZ. List of valid resources from app registration: 00000002-0000-0000-c000-000000000000, 00000003-0000-0ff1-ce00-000000000000.\r\nTrace ID: KKKKKKKKKKKKKKKKK\r\nCorrelation ID: CCCCCCCCCCCCCCCCCCC
I can't see why it would work for one user but not another if both are in different tenant/Azure ADs to where the app is created.
If you were developing an native app which access the multi-tenant web API which also developed by you, you can set the add the clientId of native app to the manifest of web app's manifest with knownClientApplications property. So that when other tenant's users access the multi-tenant web API, it will also register the native app to their tenant.
Refer the code sample below which demonstrates a Windows Store application calling a multi-tenant web API that is secured using Azure AD:
active-directory-dotnet-webapi-multitenant-windows-store
I have a web forms application which I developed for testing Authentication/Authorization scenarios. While creating the test project, I selected "No Authentication" which created my project to have no authentication mechanism code. I published the web site to my azure tenant and enabled the Azure Active Directory Authentication from the "Authentication / Authorization" under features. I created an Azure AD app pointing to my web application. After hitting the default page, the app now authenticates and everything seems to work fine.
However, when I run the app locally from within Visual Studio, I am not able to get the user information as there are no appropriate headers available, eg X-MS-CLIENT-PRINCIPAL-NAME. My next step was to call the graph API to get the detailed user information.
NOTE: I am able to include the OWIN code in my web project to authenticate users, but I want minimal code change to my existing on-prem windows authentication application.
Any help / guidance
However, when I run the app locally from within Visual Studio, I am not able to get the user information as there are no appropriate headers available, eg X-MS-CLIENT-PRINCIPAL-NAME. My next step was to call the graph API to get the detailed user information.
This is expected. The X-MS-CLIENT-PRINCIPAL-NAME header (and related headers) is added by the Authentication / Authorization module which runs in app service. when you run locally from Visual Studio, you won't have this module and thus won't have this request header.
If you want to use the same code both locally and in App Service, instead of looking at the request headers, I suggest using .NET APIs which surface up user information, such as ClaimsPrincipal.Current.Identity.Name. This should be populated correctly whether you're using Windows Authentication locally or Authentication / Authorization in Azure App Service.
You can find more information about the underlying mechanics of Authentication / Authorization here: https://cgillum.tech/2016/02/01/architecture-of-azure-app-service-authentication-authorization/.