Is there an equivalent to this command on server 2008r2? I'm trying to configure the dynamics 365 App for Outlook and this command is one of the steps. It looks like it wasn't added until 2012r2.
No - because "The Add-AdfsClient cmdlet registers an OAuth client" and ADFS 2.0 has no OAuth support.
This was only added in ADFS 3.0 (partially) and the full stack is available in ADFS 4.0.
Related
I have an on-premise CRM 2016 system that uses Active Directory and when I attempt to access the OData API from a desktop app, using network credentials, I get an un-authorised message.
After looking into this it would appear that I need to authenticate using OAuth which in turn would require installing AD Federation Services.
Before going down this path I would like to know if this is the correct approach to take?
I've been able to find plenty of examples on how to acheieve this using CRM online/Azure AD, but not much for on-premise 2016.
If your desktop app built on .NET framework and runs in the same local network as your CRM server then you can use XRM Tooling SDK instead.
https://learn.microsoft.com/en-us/previous-versions/dynamicscrm-2016/developers-guide/dn689057%28v%3dcrm.8%29
This SDK lets you create a CrmServiceClient object using a connection string from your configuration file. This object implements the IOrganization interface which means it has the CRUD methods you can use against your CRM.
CrmServiceClient service = new CrmServiceClient(ConfigurationManager.ConnectionStrings["mycrmconnstr"].ConnectionString);
Yes, that's the way to make it work with CRM On-Premise.
You will have to install and configure ADFS (according to documentation ADFS 3.0 is the latest version supported). Once everything is set up, the overall process is quite similar to when you're doing it in Online with AAD:
Register application
Add-AdfsClient -ClientId <CLIENT_ID> -Name <APP_NAME> -RedirectUri <REDIRECT_URI>
Grant application permission to CRM
Grant-AdfsApplicationPermission -ClientRoleIdentifier <CLIENT_ID> -ServerRoleIdentifier <CRM_URI>
Connect using Authorization Code Grant
Authorization Code is the only flow implemented in ADFS 3.0 (that's why I mentioned it before) so don't waste 4 o 5 hours trying to use Implicit like I did :(. ADFS 4.0 implements it (along with Client Credential and Resource Owner Password Credentials but in theory is not supported (although I've seen it working).
As you said the process is not well documented but you'll find some questions on forums or some blog post that will help you. I found THIS one very helpful, even though is not Dynamics related.
I have several services written with ASP.NET 4.5.2 that fetch data from an external web service. These services have worked perfectly without error for a year or so. However, the third-party supplier has recently restricted their API to requests from clients using TLS 1.1 or higher.
Our services have been failing as they are being rejected by the extrnal web service. I have checked the server we use to host our service - Windows Server 2012 R2 - and this has TLS 1.1 and 1.2 configured (I have checked the registry keys). So surely our .NET service requests should default to one of those?
The fact our services are still being rejected suggests we are still sending our requests using TLS 1.0.
How can I check if our services are using TLS 1.1 or higher? How can I enable the services to use TLS 1.1 or higher?
You can use below tool to check the TLS protocols that the client's host name is supporting.
https://www.ssllabs.com/ssltest/analyze.html
Go to this Qualys SSL Labs, enter the client host name (ex: abdc.com).
Once report is generated, scroll down to Configuration section.
You will find the status of TLS 1.0/1.1/1.2/1.3/SSL3/SSL2
To understand the relation between .Net framework & TLS, refer below link.
https://blogs.perficient.com/2016/04/28/tsl-1-2-and-net-support/
The fact our services are still being rejected suggests we are still sending our requests using TLS 1.0.
In this case you are are using TLS as a client, not a server to connect to a remote service.
I have several services written with ASP.NET 4.5.2
There are registry keys you need to change for the .NET Framework 4.5.2 in order for TLS 1.2 to be used. This is documented here in the .NET TLS guide.
Perhaps the easiest thing to do would just be to move to the latest version of the .NET Framework. If that is not possible, you can do as the guide says
Set the SchUseStrongCrypto and SystemDefaultTlsVersions registry keys to 1.
We just received an update to Dynamics CRM 9.0, but it seems like a get a unresolved reference when I try to programmatically access the Organization Service Endpoint.
The Uri I am using for this CRM online instance is https://xxxxxxxxxxxxxtest.api.crm.dynamics.com/XRMServices/2011/Organization.svc?wsdl&sdkversion=9'.
Please let me know if anything has changed that I cannot use this endpoint anymore?
Please check if the following blog article helps you. There are several different possibilities why this is happening, but with version 9, so are easily fixed:
https://community.dynamics.com/crm/b/nishantranaweblog/archive/2018/01/31/metadata-contains-a-reference-that-cannot-be-resolved-https-orgname-crm8-dynamics-com-xrmservices-2011-organization-svc-wsdl-amp-sdkversion-9-error-in-dynamics-365
Hope this helps.
The OData URL is
https://[ORGNAME].crm.dynamics.com/XRMServices/2011/OrganizationData.svc/[EntitySet]
The Organization URL is
https://[ORGNAME].api.crm.dynamics.com/XRMServices/2011/Organization.svc
(Double check the info by going under Settings -> Customizations -> Developer Resources)
2011 aka soap endpoints are deprecated, which means will be retired anytime. So you don’t have much time, earlier is better to convert to Web Api.
Beginning with the Dynamics 365 (8.0) release, a new OData 4 endpoint was added to the Dynamics 365 application stack. This endpoint is known as the Web API. The Web API provides a development experience that can be used across a wide variety of programming languages, platforms, and devices. The Web API is intended to replace the CRM 2011 endpoint, also known as the SOAP endpoint, for accessing the Dynamics 365 organization web service and other provided web services.
As of the release of Microsoft Dynamics CRM Online 2016 Update 1 and Microsoft Dynamics CRM 2016 Service Pack 1 (8.1.0), the CRM 2011 endpoint has been deprecated. The 2011 endpoint will be removed some time after the release of Dynamics 365 version 9. We plan to provide updates to the Dynamics 365 SDK assemblies and tools over the next several minor releases, retargeting them to use the Web API instead of the 2011 endpoint.
Till then check if TLS 1.2 is the issue like discussed here.
Check, please, that option "Don't use proxy server for local (intranet) address" off on Proxy tab in Network settings
I am using a digest like (but not digest) custom authentication scheme where the authentication header field of the http request contains username:encryptedtokendata
I do not have any problems with this scheme on on Windows 7 and Azure emulator. However when I deployed my service to Azure's Windows 2008 Server SP2 my authentication header fails to make it through to my wcf service. It is null.
IIS on Windows 7 & Windows 2008 Server has both anonymous and membership authentications enabled (because i use membership for certain authentications). Every other authentication is disabled.
Any ideas what might be causing this issue for me? I searched stack-overflow and google up and down without any luck.
I would check and make sure your authentication module is getting installed in Azure and that it is listed correctly in IIS there. You should be able to remote into the instance and troubleshoot it just like you would on premise.
I need to integrate shibboleth in my application. My application is .net web application. May I know how to do this one? I have a separate server (ubuntu server) in which shibboleth idp and sp installed with apache configuration.
I made lot of search on this. but I can't able to get the correct information for this one Can anyone suggest me some url or point what i need do to get it work?
You could implement (Windows Identity Foundation) WIF in your ASP.NET Web App.
If you have Active Directory Federation Services (which basically make Active Directory speak SAML2 protocol and WS-Federation protocol), you can have ASP.NET with WIF trusting (thru WS-Federation) ADFS V2, trusting (thru SAML 2 protocol) Shibboleth.
You can find additional information in these posts. You can find sample screen shots with SharePoint instead of ASP.NET in this post (sorry it's in French). A white paper explains how to implement.
If you don't have Active Directory and ADFS V2, you may want to use SAML2 protocol extension for WIF and this thread may help.
Similar to : Single Sign on using Shibboleth