In this article we will discuss why Microsoft SharePoint Online integration in D365FO does not work in a local development environment (OneBox) and how to fix the issue.
Definition of terms
Term | Definition |
---|---|
OneBox instance | A development environment deployed on a local machine. |
Azure instance | A development environment deployed in the cloud. |
Configure SharePoint storage
Microsoft SharePoint Online is one of the storage locations in D365FO that are supported natively. Currently, on-premise SharePoint (a local SharePoint server) is not supported.
To configure SharePoint storage in D365FO, follow these steps:
- Go to the Document management parameters page.
- On the SharePoint tab, in the Default SharePoint server field, review the host name that was automatically detected for the SharePoint site. Typically, the SharePoint host is in the form tenantname.sharepoint.com, and accounts on that tenant are usually in the form user1@tenantname.onmicrosoft.com.
- Click Test SharePoint connection to test the specified SharePoint host name. This verifies if the security and the license are working correctly.
- Click Open SharePoint to open the specified SharePoint host name in a browser. Note that this does not verify the security, it just opens the specified SharePoint’s URL in a browser.
SharePoint communication works for a current user only if the following conditions are met:
- An Office 365 license is associated with the user’s account.
- The user is a typical user in the tenant, not an external user.
- There is a SharePoint site for the tenant.
- Properly set the following configuration keys in the web.config file:
- Aad.AADTenantId – AAD Tenant ID in the form tenantname.com
- Aad.Realm – Microsoft Dynamics ERP Application ID
- Aad.ACSServiceEndpoint – ACS service endpoint
- Aad.ACSServicePrincipal – Azure ESTS Service Application ID
- Infrastructure.S2SCertThumbprint – S2S certificate thumbprint
An example of configuration key values
If all conditions are met, SharePoint communication works fine on any D365FO instance deployed in Azure but not on an instance deployed in OneBox.
In OneBox instance we get the error: Unable to communicate with the SharePoint server: tenantname.sharepoint.com.
Troubleshooting
To find out why the communication does not work, we need more detailed error description. Luckily, it can be found in Event Viewer under the node Applications and Services Logs | Microsoft | Dynamics | AX-DocumentManagement | Microsoft-Dynamics-AX-DocumentManagement/Operational.
As you can see from the error description, the real cause for the communication failure is that we are not authorized to obtain the security token for communication with SharePoint. An error occurs on a token creation.
The system uses the S2S certificate to sign the AAD access token request. The token grants AOS the access to SharePoint in the name of the given users. This perfectly works on Azure but fails on OneBox.
If we compare the S2S certificates from an Azure instance and from OneBox instance for the same tenant, we can see that they differ. It turns out that the S2S certificate from Azure instance is added to the AAD application Microsoft Dynamics ERP service principal credentials to enable the trust, while from OneBox instance it is not.
Application Microsoft Dynamics ERP on Azure
The S2S certificate in OneBox instance
The S2S certificate in Azure instance
Enable authentication with the S2S certificate from OneBox in AAD
To fix this problem we need to run a few PowerShell commands to add the S2S certificate from our OneBox instance as a new credential to the service principal for the Microsoft Dynamics ERP application. To do that, follow these steps:
- Open Manage computer certificates.
- Select the S2S certificate aadclient.erp.ppe.dynamics.com under the node Personal | Certificates.
- Right click on the certificate and select All Tasks | Export...
- In the Certificate Export Wizard select:
- No, do not export private key
- Base-64 encoded X.509 (.CER)
- Filename
- Run Windows PowerShell ISE as administrator.
- Check if the MSOnline module is installed in the Windows PowerShell – if not refer to https://www.powershellgallery.com/packages/MSOnline/1.1.183.8 how to install the module.
- Check if you have proper permissions on Azure to maintain credentials for applications. Otherwise the next step will fail.
- Execute the following commands to add the S2S certificate as a new credential to the service principal for the Microsoft Dynamics ERP application. Before that replace the placeholder <Certificate> with the filename you selected in the step 4.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
<# Connect to AAD #> Connect-MsolService <# Microsoft Dynamics ERP Application id #> $appid = "00000015-0000-0000-c000-000000000000" $cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate <# Filename with the path of the exported S2S certificate #> $cer.Import("<Certificate>") $binCert = $cer.GetRawCertData() $credValue = [System.Convert]::ToBase64String($binCert); <# Add the certificate to the Microsoft Dynamics ERP application #> New-MsolServicePrincipalCredential -AppPrincipalId $appid -Type asymmetric -Value $credValue -Usage verify |
Update web.config with Azure ESTS Service Application ID
SharePoint integration will start working after we change the value of the configuration key Aad.ACSServicePrincipal in web.config. The value of this key in OneBox instance (00000001-0001-0000-c000-000000000000) is not the same as in Azure instance (00000001-0000-0000-c000-000000000000). Why the values differ is not clear.
Application ID provided in OneBox instance (00000001-0001-0000-c000-000000000000) does not exist in AAD, but Application ID provided in Azure instance (00000001-0000-0000-c000-000000000000) exists and defines the Azure ESTS Service application (aka Access Control Service – ACS).
To change the values in the web.config file, follow these steps:
- Go to the ..\AOSService\webroot folder.
- Find and open the web.config file as administrator.
- Find the configuration key Aad.ACSServicePrincipal.
- Replace the existing value "00000001-0001-0000-c000-000000000000" with the new one "00000001-0000-0000-c000-000000000000".
- Save the changes and close the file.
To check if SharePoint integration works now, click Test SharePoint connection on the Document Management Parameters page in D365FO. You should now get the message: Successfully connected to SharePoint server 'tenantname.sharepoint.com'.
The proper solution: Create a new S2S Self-Signed certificate
To solve the SharePoint communication problem for OneBox, we used the S2S certificate which is already part of OneBox instance provided by Microsoft. This means that this certificate is the same in all deployed OneBox instances around the globe, which could pose a security risk.
To avoid this risk, we need to create our own S2S Self-Signed certificate in OneBox instance, add it to the Microsoft Dynamics ERP service principal on AAD to enable the trust and replace the value of the configuration key Infrastructure.S2SCertThumbprint in the web.config file with the thumbprint value of our newly created certificate.
To create a self-signed certificate, follow these steps:
- Run PowerShell ISE as administrator.
- Execute the following command to create the certificate. Before that replace the placeholders <Certificate Name>, <Valid From> and <Valid To> with the desired values.
New-SelfSignedCertificate -Subject "CN=<Certificate Name>" -CertStoreLocation "Cert:\LocalMachine\My" -KeyExportPolicy Exportable -KeySpec Signature -NotBefore <Valid From> -NotAfter <Valid To>
- Open Manage computer certificates.
- Select the created certificate under the node Personal | Certificates.
- Right click on the certificate and select All Tasks | Manage Private Keys...
- Add users IUSR and NETWORK SERVICE and set the Read permission for both.
To add the created certificate to the Microsoft Dynamics ERP application on Azure, follow the 8 steps outlined in the beginning of the Enable authentication with the S2S certificate from OneBox in AAD chapter. Be careful to export the newly created certificate and not the default one which is indicated in the step 2.
If everything is done properly, testing of SharePoint connection using the new certificate should be successful.
On new April 2022 OneBox
April 2022 OneBox comes with provisioning script that you should run before first use. It assumes that you register a new AAD application and use it when running Generate Self-Signed Certificates script, but it is hard to establish trust between this application and SharePoint.
The easiest recommended approach is to reuse the standard Microsoft Dynamics ERP application:
- Run the script Generate Self-Signed Certificates (Run as Admin) with ApplicationID 00000015-0000-0000-c000-000000000000 and thumbprint of your S2S certificate.
- Adjust web.config
<add key="Aad.ACSServicePrincipal" value="00000001-0000-0000-c000-000000000000" />
<add key="GraphApi.GraphAPIAzureAccessControlPrincipalId" value="00000001-0000-0000-c000-000000000000" /> - Run Admin User Provisioning tool.
- Restart IIS and Batch serivice.
The script will fail when running more than once! Delete the generated certificates and revert C:\DynamicsTools\CleanVHD to original content before rerunning it.
On new December 2022 OneBox and newer
Follow the steps for April 2022 OneBox, but the script does not update web.config with your S2S certificate thumbprint anymore (bug reported). Therefore you have to manually replace the current value of Infrastructure.S2SCertThumbprint with your S2S certificate thumbprint in the whole file (5 appearances).
If your account has MFA enabled
Many companies enforce multi-factor authentication (MFA) for all accounts which is however a good practice. The problem is that command Connect-MsolService does not work with MFA enabled accounts, even if they have just conditional MFA and are used from location where MFA is not activated. The reliable alternative is to use script Add-CertToServicePrincipal.ps1 that you can find in Microsoft Dynamics 365 Finance + Operations (on-premises), Deployment scripts (version 2.19.1 or later) instead of the script that starts with Connect-MsolService above in this article.
Hi admin,
I tried to To add the created certificate to the Microsoft Dynamics ERP application on Azure, follow the 8 steps outlined in the beginning of the Enable authentication with the S2S certificate from OneBox in AAD chapter. But Power Shell show errror at line “Connect -MsolService”. I make sure that the MSOnline module is already installed in the Windows PowerShell.
Error in Power Shell.
Connect : The term ‘Connect’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:2 char:1
+ Connect -MsolService
+ ~~~~~~~
+ CategoryInfo : ObjectNotFound: (Connect:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Please give me an advise.
Thank you so much
Hi Nguyễn,
Please install the Connect-MsolService using the following steps:
– Go to PowerShell as Administrator on your OneBox machine
– Run the command:
Install-Module MSOnline
– Run the command:
Install-Module AzureAD
After the successful installation the command Connect-MsolService should be working as expected.
Hope that this helps.
Kind regards,
Klemen
This helped me. Thank you!
I am getting the same error “unable to communicate” but I cannot find the error in event viewer log. Also I can see my aadclient certificate is expired on local machine.
What do you suggest in this case.
Hi Abdul,
I see that the reason you can not connect to SharePoint is because of the expired certificate. To resolve the issue, you need to create a new self-signed certificate as described in the chapter The proper solution: Create a new S2S Self-Signed certificate. If you did everything correctly, the connection to SharePoint will be successful.
Kind regards,
Vilko
I did created SSL certificate and updated web.config, stil unable to communicate with Sharepoint. I updated web.config SSL certificate thumbprint also.. still it did not work. any ideas?
The April 2022 D365FO Onebox has unique generated certificates and environment is linked to your Azure application. I have added the chapter describing the specifics while you still have to do other steps.
Hi, i’m trying to follow your guide for the April 2022 update, but I can’t get it to work.
My onebox is already setup and running, so I have already run the provisioning scripts. What should I do now?
You say to: “Run the script Generate Self-Signed Certificates (Run as Admin) with ApplicationID 00000015-0000-0000-c000-000000000000 and thumbprint of your S2S certificate.”
But how can Ax work if I use the generic application ID 00000015-0000-0000-c000-000000000000 instead of my Azure application id?
Do I have to provide a certificate or can I let the provisioning script to generate one?
And what do you mean exactly with “Delete the generated certificates and revert C:\DynamicsTools\CleanVHD to original content before rerunning it.”
I tried a lot of combination but none seems to works.
I will be very grateful if you provide a more detailed guide in this issue
Hi Omar,
This article describes how to establish the trust between Azure application called Microsoft Dynamics ERP (created by Microsoft) with ID 00000015-0000-0000-c000-000000000000 and your SharePoint. Up to April 2022 all local OneBoxes were using this ID and it still works if you follow our steps.
However you can create your Azure application and use its ID, but then you have to adjust the scripts.
If you have an already provisioned environment I would recommend the following:
Hi,
I tried what was described in the article on VHD 10.0.37 OneBox.
But unfortunately I get the following error.
Do you have any ideas what could be the problem?
“ComponentName SharePointHelper
Operation VerifyAuthentication
httpStatusCode 401
requestId 54dfefa0-006f-7000-9950-8220941fe6c4
errorMessage
responseLength 74
responseHeaders {“x-ms-diagnostics”:”3001000;reason=\”There has been an error authenticating the request.\”;category=\”invalid_client\””,”sprequestguid”:”54dfefa0-006f-7000-9950-8220941fe6c5″,”request-id”:”54dfefa0-006f-7000-9950-8220941fe6c5″,”date”:”Mon, 20 Nov 2023 08:11:03 GMT”}”
Thanks in advance for your help
Regards,
László
Hi László,
Is this the error that you get in Event log?
If not check the Event log if you find more informative error there. The current error does not tell much.
The procedure described in the article till works for us on 10.0.38 Preview and also on latest VHD.
Hi,
Thank you for the feedback.
Yes, I copied the error from the event log.
Did you have to configure something in the Azure portal?
You do not have to create a new Azure application, because we are using the existing application created by Microsoft. However, you have to do all the steps described in the article.
On new VM (April 2022 or later) you can run the provisioning script only once. You can backup C:\DynamicsTools\CleanVHD and restore it to rerun the script.
My advice for your error would be to run the process again with clean CleanVHD.
Thank you for this article. It is very useful.
Couple things or problems:
Connect-MsolService is not working with MFA
I did this steps with Connect-AzAccount and New-AzADAppCredential
As alternative I think you can just go to your Azure Application and upload Certificate there
I did not generate Certificate manually, I used MS provided script “Generate Self-Signed Certificates”
And then used “aadclient-onebox-locator1-dynamics-com” certificate
Issue I still have:
When testing sharepoint connection I got this info:
“You are not authorized to connect to ‘<SomeName>.sharepoint.com'”
EventViewer shows me this:
ComponentName SharePointHelper
Operation VerifyAuthentication
httpStatusCode 401
responseHeaders {“x-ms-diagnostics”:”3005004;reason=\”The token does not contain valid algorithm in header.\”;category=\”invalid_client\””,”sprequestguid”:”<Some GIUD>”,”request-id”:”<Some GUID>”,”date”:”Fri, 19 Jan 2024 12:00:46 GMT”}
Do application need to have some additional permissions to sharepoint?
Getting same error as you, can you post here if you get any answers
In last days we are actively working on this issue. We have managed to find some working solutions and will publish it in next days when we day when we finish the research. Till then a hint, it works best when registering application S2S certificate with Add-CertToServicePrincipal.ps1 script (from infrastructure scripts for on-premises deployments from the Shared asset library) and use Microsoft Dynamics ERP application (00000015-0000-0000-c000-000000000000), not your own.
Hi Justas, Lakshmi,
After longer investigation we can say that we always get the error “The token does not contain valid algorithm in header.” if we use our Azure application, but not if we use application Microsoft Dynamics ERP which is managed by MS. Even though MS recommends to use an own application (for local and cloud devbox), SharePoint does not trust it. We have a MS support case open, but not results yet.
The procedure described in this article still works. Just when using MFA enabled account do not use the script that starts with Connect-MsolService (above in this article). Instead use the script Add-CertToServicePrincipal.ps1 that you can find in Microsoft Dynamics 365 Finance + Operations (on-premises), Deployment scripts (version 2.19.1 or later). More details added in last section of the article.
I don’t have that script because I just have a downloaded VHD – not on-prem.
I was able to use connect-msolservice and add the service principal credential (cert from running the scripts to set up the box) to Microsoft Dynamics ERP but I still get the “The token does not contain valid algorithm in header” and it seems to use network service account (Says Security UserId=”S-1-5-20″. Do you other guys have this working? I added the credential using the admin account for my instance. The admin account has access to SharePoint. Not sure what I’m missing here!
Hi Laura,
The Add-CertToServicePrincipal.ps1 script in included in Microsoft Dynamics 365 Finance + Operations (on-premises), Deployment scripts ZIP that you get on LCS>Shared asset library\Model. Take the latest version.
The procedure described in this article (updated February 3) is working for us on local and cloud devbox. If you send me your email to miha.vuk@docentric.com, I can send you the exact steps.
As this article has grown over time and it is hard to read, we also plan to publish a new one with updated clear steps and just the relevant content.