In doing some more testing today, I am finding that when I get an access token for a user that has been added to a tenant via the Azure B2B feature, I cannot access the site content using the Office 365 APIs.
Is there any plan to enable this scenario by RTM for Azure B2B? I'm finding more and more blocking scenarios like this where a user has been granted access to a resource, but access through the Office 365 APIs is not working.
Related
I have been using Sharepoint Online REST API to integrate with my O365 AddIn app which is working perfectly fine for my Old O365 tenant.
However I am getting an error while I am trying to call any API with the Bearer token that I get for my new O365 tenant app.
{"error":"invalid_request","error_description":"Token type is not allowed."}
Is the auth token URL changed for new tenants, or is it something else.
I am using https://accounts.accesscontrol.windows.net/{{tenant_id}}/tokens/OAuth/2
Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), got retired on November 7, 2018. This retirement doesn't impact the SharePoint Add-in model, which uses the https://accounts.accesscontrol.windows.net hostname (which isn't impacted by this retirement).
Check out Impact of Azure Access Control retirement for SharePoint add-ins.
Note that, you can connect SharePoint directly to Azure AD using token issuance policies.
SharePoint 2013, 2016, and SharePoint Online customers have long used ACS for authentication purposes in the cloud, on-prem, and hybrid scenarios. Some SharePoint features and use cases will be affected by ACS retirement, while others will not. The below table summarizes migration guidance for some of the most popular SharePoint feature that leverage ACS:
Authenticating users from Azure AD
Previously, Azure AD did not support SAML 1.1 tokens required by SharePoint for authentication, and ACS was used as an intermediary that made SharePoint compatible with Azure AD token formats. Now, you can connect SharePoint directly to Azure AD using token issuance policies.
App authentication & server-to-server authentication in SharePoint on-prem or SharePoint Online – SharePoint add-in registrations done through appregnew.aspx etc.
Not affected by ACS retirement; no changes necessary.
Low trust authorization for SharePoint add-ins (provider hosted and SharePoint hosted)
Not affected by ACS retirement; no changes necessary.
SharePoint cloud hybrid search
Not affected by ACS retirement; no changes necessary.
We had the same issue when using app-only, ClientID / ClientSecret based authentication in a tenant, that was recently created. In our old tenant (created in 2013) we could use the same authentication method without any problem. As it turned out, new tenants have a standard setting in DisableCustomAppAuthentication property, that disable this kind of auth., however it can be overriden using this command:
Set-SPOTenant -DisableCustomAppAuthentication $false
Source:
https://sharepoint.stackexchange.com/questions/284402/sharepoint-online-authorization-issue-token-type-is-not-allowed
https://sharepoint.stackexchange.com/questions/286693/getting-invalid-request-token-type-is-not-allowed-error-while-accessing-lists
Furthermore:
https://learn.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azureacs
Azure Access Control (ACS), a service of Azure Active Directory (Azure
AD), has been retired on November 7, 2018. This retirement does not
impact the SharePoint Add-in model, which uses the
https://accounts.accesscontrol.windows.net hostname (which is not
impacted by this retirement). For more information, see Impact of
Azure Access Control retirement for SharePoint Add-ins. For new
tenants, apps using an ACS app-only access token is disabled by
default. We recommend using the Azure AD app-only model which is
modern and more secure. But you can change the behavior by running
‘set-spotenant -DisableCustomAppAuthentication $false' (needs the
latest SharePoint admin PowerShell).
More details:
https://www.koskila.net/literally-breaking-changes-to-app-authentication-on-sharepoint-%F0%9F%98%B5/
We are designing a Dynamics 365 solution for a customer that already have an existing tenant with an Azure AD that uses federation through AD-FS.
We would like to design a solution using a separate tenant and Azure AD with Dynamics 365 (online). The idea would then be that we should invite users from their tenant to "our" tenant using Azure AD B2B.
We've found that there are limitations using Unified Service Desk client and using the users own email, using this approach. Are there other known limitations?
Could this be solved in a better way, still using two separate tenants?
Microsoft states that the following features are not supported when using Azure B2B together with Dynamics 365:
Unified Service Desk client
Dynamics 365 App for Outlook
Invited users cannot perform email activity using their own email address
Office 365 Groups
Read details at link
I have found there's the Office 365 Management API in Azure Active Directory Enterprise Application as attached after I have grant Office 365 API access to one of my registered app.
I'm wondering what impact would I face if I delete the Office 365 Management API in Azure Active Directory Enterprise Application?
Thank you in advance!
As I know, if you delete Office 365 Management API, you just cannot use it anymore, and there is no impact for the registered app.
When you registered your application under App Registrations, gave it permissions to the API and then performed the consent to those permissions...it automatically creates the registration in Enterprise Applications. Basically, the registration under Enterprise Applications is the instance of the app for that directory (tenant). If the app was multi-tenant, it would also need to be registered in Enterprise Applications in the other tenants needing to access the application. If you remove the registration from under Enterprise Applications it will remove access to the app for that tenant. In order for users in that tenant to regain access to the application, the app would need to be re-registered under Enterprise Applications and the consent would have to happen again.
I have a scenario that I am hoping someone can assist me with. I have a requirement to build an extranet in SharePoint Online (Office 365).
We have a main Office 365 Tenant. There are 15 member organisations that need access and these DO NOT have Office 365. on premise only.
So I can use Azure B2B to grant access to SharePoint Sites no problems. I need the social aspect and Yammer Fits PERFECTLY but identities are separate.
I can create and External Yammer Network and invite users but obviously these are a separate set of credentials to that of Azure AD.
Has anyone done such a thing and is there a way to grant Azure B2B users access to an external Yammer network?
Yammer should allow you to sync with your Azure Active Directory. This should allow users to have the same logins.
Here is some information I found on this matter:
https://products.office.com/en-gb/yammer/yammer-network-administration
I am Using ADAL libs for java to connect MS Dynamics CRM in my backend application. I registered my trial version of CRM Azure Active Direstory and I got clientID and clientsecret from there. So now I can able to connect with my crm.
But my question is If I have multiple CRM Account how should I do this.Is there any api to register the CRM in azure active directory or is there any API to do that using the CRM crendials?
Can anyone please explain me.
AFAIK, the MS Dynamics CRM only support Authorization code grant flow(OAuth).
If you were developing an web app, it should works well for your scenario. Since every user could sign-in the web app and than the web app can delegate the user to integrate with MSDynamics.
More detail authentication with Microsoft Dynamics 365, you can refer the document below:
Connect to Microsoft Dynamics 365 web services using OAuth