PowerPlatform-DataverseServiceClient
PowerPlatform-DataverseServiceClient copied to clipboard
microsoft
Please add support for AD authentication type
This is an area we are exploring but have not committed too as of yet. In general we are strongly encouraging the use of ADFS for On Premises systems.
Also interested in the possibility of the AD authentication type. Please add this.
Please. We want to (and partially do) upgrade our services to .NET Core and further. But without .NET Core client libraries to connect to On Premise Dynamics 365 it is a no go. Microsoft wants us to upgrade everything to .NET (core), but the Dynamics team does not, or provides a very difficult path. It should be easy and painless.
Insofar as formal support for AD, AD Federated, and Remote AD domain federation, there is an increasing potential we will be able to support it in the future based on .net 5 baseline. Still TBD as we are seeking a way to support this that would not require a patch to onPremise.
The direct issue there is the realm of things that come with AD support that were baked into the previous client. Most of which are dropped with the WS-TRUST deprecation for Online.
You can use oAuth onPremise assuming you have an ADFS deployment to work with, we do document setting that up in the onpremise deployment documents for CRM 2016+. and this is what we would recommend when working with OnPrem for now.
@MattB-msft, all server-to-server auth schemas are officially NOT supported for on-premise. It's documentation issue, I have support ticket about that: 2107050040001964. OAuth silent authentication seems partly working, but with IntegratedSecurity option but that means running in context of ActiveDirectory authenticated user process.
Any news on this? We have migrated to v9 and want to migrate everything to .Net core to take full advantage of it.
@MattB-msft you mentioned that there is a document on how to setup ADFS oAuth for CRM 2016+. Could you provide a link. All I can find is how to setup ADFS but without oAuth. Why was WS-Trust dropped just because it was depreciated for Online?
@ONYXDave there is no such document, only this video: https://www.youtube.com/watch?v=26OnuDSOZf4
This is documented folks. It starts with configuring IFD: https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/deploy/configure-internet-facing-deployment?view=op-9-1 then once configured.. you use this command ( Doc) to enable OAuth in CRM OnPrem : https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/deploy/post-installation-configuration-guidelines-dynamics-365?view=op-9-1#configure-the-oauth-provider
Also, S2S was not stated to work for OnPrem @FixRM , We realized that the doc's were misleading there and fixed that recently to clearly state that S2S only works online.
for onPrem you need to use named user accounts
I guess folks are asking how to setup S2S (non-user interactive) auth process @MattB-msft. This video basically tells how to do it with OAuth password flow which is suitable for the task. It requires lot of additional steps on top of documented configuration.
@FixRM In on-prem .. Application Users ( S2S / Confidential Client ) are not support at all. you would use a named user ( using oAuth is fine ) for that configuration. I will look thought the video and pass it on to our Auth folks to have a look at updating our documentation with any missing steps. Thanks for pointing it out.
Our documentation was not clear on the subject of application users up till recently when the question came up and we clarified the documentation.
There is an undocumented path of using Azure AAD for OnPrem that can support an Application User / S2S path. Its undocumented as there are unsupported modifications required to support Dynamics's Outlook Web Integration which we hope to sort out in the future.
@MattB-msft that's right, we use named users. The problem here is to somehow get OAuth token without user interaction
Can you reuse some code from https://github.com/Data8/DataverseClient, since it is MIT?
As long as you comply with the license rules associated to this repro. You are free to use it.
Before you do though, which part are you interested in? There are several areas still under development.
MattB
From: Andrey Belykh @.> Sent: Wednesday, February 9, 2022 1:38:09 PM To: microsoft/PowerPlatform-DataverseServiceClient @.> Cc: MattB @.>; Mention @.> Subject: Re: [microsoft/PowerPlatform-DataverseServiceClient] Please add support for AD authentication type (#110)
Can you reuse some code from https://github.com/Data8/DataverseClient, since it is MIT?
— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/PowerPlatform-DataverseServiceClient/issues/110#issuecomment-1034215843, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQUENGYSV62FGRXL4SI4NLU2LNEDANCNFSM4Z3PBRRQ. You are receiving this because you were mentioned.Message ID: @.***>
As long as you comply with the license rules associated to this repro. You are free to use it. Before you do though, which part are you interested in? There are several areas still under development. MattB
If Microsoft could incorporate a code from https://github.com/Data8/DataverseClient into this line, would be great. Even greater, if you could implement missing AD authentication
Ah, I'm sorry I misunderstood your question. I was looking at this thread on a phone.
You were asking if the DV ServiceClient could take code from another, non-Microsoft project. In short, 'it depends', there are a lot of rules we have to follow concerning accepting code from developers outside of Microsoft.
In the case of AD authentication support, that was intentionally removed from the Dataverse ServiceClient as part of the .net port. That code, along with the WS-TRUST supporting code, had a lot of dead code from the various evolutions over the years that CrmServiceClient has been in operation. There were (past-tense) technical issues with AD support in the .net core libs and the API targets that blocked the use of AD.
We are looking at adding support for OnPrem AD back in, however we may or may not add support for WS-TRUST for onPrem on .net core.
Ah, I'm sorry I misunderstood your question. I was looking at this thread on a phone.
You were asking if the DV ServiceClient could take code from another, non-Microsoft project. In short, 'it depends', there are a lot of rules we have to follow concerning accepting code from developers outside of Microsoft.
In the case of AD authentication support, that was intentionally removed from the Dataverse ServiceClient as part of the .net port. That code, along with the WS-TRUST supporting code, had a lot of dead code from the various evolutions over the years that CrmServiceClient has been in operation. There were (past-tense) technical issues with AD support in the .net core libs and the API targets that blocked the use of AD.
We are looking at adding support for OnPrem AD back in, however we may or may not add support for WS-TRUST for onPrem on .net core.
Thanks a lot for clarification.
Good news / bad news sort of thing here folks. - Bit of an update... The next drop of the client will have the groundwork for OnPrem in it using AD auth. Its full framework only though. so .net core will not work with AD Auth on Prem.
The initial bits will be limited in what they can do, all the Async operations should work, however .Clone operations do not work as of this check-in.
There is a lot more work required to support AD in .net core based on our current clients, we will continue to look at it as we move forward with this client.
Good news / bad news sort of thing here folks. - Bit of an update... The next drop of the client will have the groundwork for OnPrem in it using AD auth. Its full framework only though. so .net core will not work with AD Auth on Prem.
The initial bits will be limited in what they can do, all the Async operations should work, however .Clone operations do not work as of this check-in.
There is a lot more work required to support AD in .net core based on our current clients, we will continue to look at it as we move forward with this client.
Good news. Hopefully .net core support in the future.
By the way, it is OK (for us) if the AD support is only for Windows on .Net 6, Linux can come later or never.
Our goal is to allow AD authentication to work for .net core, currently though we have it working only in full framework. Depending on how far we get, we may ship the next drop with only .net framework support.
For transparency, the issue is more with how our API manages the configuration of various types of authentications for on-premises vs anything specific about AD itself, at least we have not discovered anything specific to .net core yet :)
Ok folks, We have been at this for a few days now across a few teams.
Short story is this:
AD Auth over .net core is not going to work based on our current on-premise Server infrastructure.
The issue comes down to .net core + removing support both methods of TransportSecurty Bindings we use to secure AD credentials on the wire. Those protocols are tied to Windows's and so far the .net core team has decided to not support them.
We are discussing adding support for AD auth in a different way to the onprem servers, however that is not going to help with existing deployments as any change we do there would be patched into in a service release and apply only going forward.
At this point we are going to ship AD support for Full Framework in the next drop and turn our attention to making claims and oAuth work properly for On-Premises in full framework and .net core.
Sorry for the bad news there.
@MattB-msft yeah, so:
1 - The entire purpose of this library is to move away from LEGACY Windows-only .NET 4.x. It is very important that you stop calling it "full" framework, because it's not "full" in any other way than "fully legacy", and no one cares about it, except people maintaining legacy software, and the entirety of Microsoft has clearly stated that REAL .NET (meaning .NET 6 and above, not the legacy one) is the way forward, only Power Platform people seem to not have noticed this.
2 - If the purpose of the library cannot be fulfilled due to whatever legacy reasons, then this library has no reason to exist at all, because Microsoft.Xrm.Sdk has been working just fine (for legacy .NET) for decades, and this library CANNOT replace it because it doesn't support the use cases supported by the former.
All in all, every single day I'm more and more thankful for having moved away from legacy, XML bloated, limitation-ridden CDS.
I agree with fberasategui. Hope was on .net core. To migrate all services to the new platform. Otherwise, this library makes no sense.
@fberasategui I am unclear as to what your concern is, we are attempting to add in AD support at the request of the user population who is still working against the On-Premises configuration. Regarding your objection to the term ".net Full Framework, or .net Framework" this is what the .net team calls that system. We didn't coin that term.
The issue, as I outlined, is that the .net core ( 3.x - 7 as if this writing) does not include support for the security / encryption system for the transport layer required to support AD authentication to the Dataverse server. It actually does not have anything to do with the Xrm Library.
@impr3ssi0n This lib is 100% .net core.
We are, however, we are limited by what .net core and its supporting modules can actually support, in this case AD to the Dataverse Servers on-premise. Thus, when running it under .net core there will be a set of features that are not enabled.
@MattB-msft
I am unclear as to what your concern is
My concern is that unfortunately I am tied to maintaining legacy projects on your legacy platform, that's not even capable (not even with all the money and manpower in the world) to keep up with the advancements in technology your own company produces.
Luckily enough, the fruitless discussion about how your platform has no proper abstractions (from almost 2 years ago now, of which of course NOTHING has changed in 2 years) was an eye opener for me to realize that I should move off of it, and all our greenfield projects since then were based on a much better platform: mine.
we are attempting to add in AD support at the request of the user population who is still working against the On-Premises configuration
No you aren't. As other people have stated here, again: the main purpose of this library is to move away from legacy .NET. If it can't provide that, then it's worthless. Why would I refactor a huge CRM codebase with hundreds of plugins, external APIs, services, and a lot of stuff that works fine today using Microsoft.Xrm.Sdk, if by doing that I will still be stuck in legacy .NET instead of the real one?
we are limited by what .net core and its supporting modules can actually support
Ah, yes. This is 100% Microsoft mentality. If something isn't built-into the framework that means it can't exist. Ever. It's not like your team (which I'm sure has budgets in the order of several hundred million dollars annually) could spend resources on actually implementing whatever stuff is needed to support your legacy platform on real .NET.
Do you have a good article that describes how to connect to on premise using this library? Most of the documents I can find are about the old (Microsoft.Xrm.Sdk) library. Is it only possible if IFD is configured?
@abelykh0 - its only possible with IFD + OAuth configured. if you want to use the CrmServiceClient, that does support AD and IFD scenarios without oAuth
The Dataverse ServiceClient itself will support ADFS 2019+ for onPrem oAuth, That said, at the moment, we are suggesting folks use the external auth hooks we provide to do it, as there is a bug in the way we are arriving at the authority information for OnPrem.
I've now got a proof of concept extension to the Data8.PowerPlatform.Dataverse.Client package to support AD authentication as well as IFD. I've still got a lot of testing & tidying up to do before it's in a state I can release it, but I can now authenticate and execute requests against a couple of test servers without claims authentication configured using .NET Core 3.1.
