Check out the latest features available in Dynamics 365 for Customer Engagement, including LinkedIn Connect, Voice of the Customer and Universal Resource Scheduling.
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
Hello everyone,This is my first post on this forum and it is quite complicated! I would really appreciate some help.
Infrastructure description: -
My company has migrated to Office 365 and we run an On-Premises / Azure hybrid infrastructure. Our on-premises Active Directory accounts are replicated (using Azure AD Connect) up to Azure AD / O365 and we use password synchronisation (not ADFS). The AD UID for each AD Account is actually replicated to Azure / 365 but only the password hash is copied, not the actual password. When the user logs on to O365 / Azure AD they are actually authenticating against Azure AD not our on-premise AD.The users all have O365 licenses along with Azure AD Premium licensing. The users can therefore login to O365 with their on-premises AD account credentials.
CRM 2013 is installed on Azure virtual machines (SQL Always-On, 2 x CRM App Servers, 2 x CRM Web Servers) and I use an Azure Load Balancer for the web servers.
This is the scenario I would like to get working: -
User logging into O365, clicking on 'My apps' and then clicking on a link to our on-premise CRM solution with Single Sign-On! This would give the users access to all their required applications directly from O365.
The problem: -
We are using the latest version of DirSync (AAD Connect) with password synchronisation and are not federating with ADFS. An IFD implementation of CRM requires a Secure Token Service but I do not wish to create (and maintain) a full ADFS implementation just for CRM which would still not give me SSO from an O365 login.
Finally, the question: -
Can I use Azure AD (as the STS) instead of ADFS for a CRM IFD implementation?
I understand that CRM does not have to use ADFS - it can use another Secure Token Service. Azure AD actually provides a Secure Token Service. I can publish the CRM application in Azure Active Directory and use the Federation Metadata Document provided by the App Endpoint to use in the CRM Claims Based Authentication configuration. CRM is happy to accept this. However, the authentication does not work.
Thanks for taking the time to read this, I would really appreciate your insights!
Azure AD is not supported by CRM.
Hi Wayne, thanks for responding.
The CRM implementation does not use Azure AD - the VMs are just hosted there as part of our Hybrid deployment. It uses our full on-premise Active Directory (with 2 of our 6 Domain Controllers running on Azure VMs).
As CRM Claims Based Authentication can utilise other Secure Token Services can it work with the STS provided by Azure AD when you register the on-premise CRM with Azure AD? As DirSync replicates the on-premise account to Azure AD with an identical SID (Security Identifier) it should be able to provide the STS Token back to CRM as would ADFS.
Oooh, I see. Totally misunderstood the first time. I still think the answer's going to be "no" because IFD is written to assume ADFS. I'd think your best bet would be to put in a request in Connect for that feature.
The alternative might be to try and build an "informal" IFD, but you're likely to run into login prompt issues and a completely unsupported deployment method.
No problem Wayne.
However, in the CRM IFD documentation it states:-
Claims-based authentication requires the availability of a security token service (STS) running on a server. An STS server can be based on Active Directory Federation Services (AD FS) V2, or any platform that provides the official STS protocol.
I am pretty sure that CRM Online uses the Azure AD mechanism and that it is really a (rather large) derivative of ADFS anyway!
I will not run an unsupported deployment as this implementation will support our entire business (>1500 users!).
why would this be unsupported?
It doesn't say it requires ADFS at all, it just should support WS-Trust 1.3 standard.
Here an example of a totally different STS:
Ping Identity with CRM2011 (just for example)
If you register CRM in the Azure AD STS and add the required Claims (Primary SID, UPN, Accountname/Name) , I would expect this to work.
you should try also to add a user using their principle name (email@example.com) instead of their pre-win2000 accountname (domain\user). This way I don't think CRM will try to use Primary SID, it will use the UPN to check the identity of the user.
I've never tried, but would expect this to be possible somehow.
Thanks for your response.
Sorry, I was trying to explain that I would not use an 'informal' IFD because it is unsupported. I fully understand that using another STS is supported and that is what I am trying to achieve with Azure AD.
Thank you for the advice and information - it all looks very interesting! I shall carry on with my research and this will help enormously.
Darrel, very interested in if you got this scenario wired up. I'm in same boat. Can you share an update? Thank you
I did get this working but I had to create a full ADFS farm implementation for the CRM IFD and then hook the Office 365 login into ADFS by creating a Claims Provider Trust for Office 365 with associated transformation rules.
I added an application to our Azure Active Directory pointing to the on-premises ADFS farm and another application pointing to the actual CRM organisation.
The upshot is that a user can login to O365 and click on the CRM application which redirects them to CRM with SSO. Also, if the user goes directly to the CRM IFD URL the system will redirect them to the O365 login for authentication and then back to CRM.
I still think that there must be a way of using Azure AD as the Secure Token Service instead of having to implement ADFS, but I haven't managed to find it!
I hope this helps.
I know this post is a little old but:
there is a way using Azure ACS to use without ADFS. There are some documents on how to do it with Sharepoint, though it would have relevance to CRM. ACS allows you to transform the claims just like ADFS does.
I have tried this and it works, and also your approach however both have a similar issue that I haven't been able to resolve.
The CRM Outlook client in multi-hop adfs mode where we need some local users and some Azure AD users needs to have the homerealmURL specified for the end users home authentication service.
For those users authenticating with Azure AD I can not get Outlook CRM Client to connect.
Did you ever try this?
This is a real interesting thread.
I am pretty in the same boat and want to achieve the same as the OP.
Basically we already use AD Azure connect to manage our MS Intune users for an MDM solution, as we already utilise and pay for the Enterprise Mobility Suite (EMS) license we also want to leverage this for our on premise CRM 2013 and Sharepoint 2013.
We currently have ADFS and WAP setup for CRM to allow our AD users to access CRM externally or via tablets but it's an early stages and we now need to make Sharepoint externally available.
What makes sense to us is as we have AD Azure Connect already syncing with our on premise AD, that we utilise Sharepoint authentication via this method rather than use ADFS.
This sort of makes our ADFS server redundant as our hope was to use ADFS for Sharepoint and Exchange as well but looking at the MS landscape, Hybrid cloud and the way services are going it makes a lot more sense and deployment is a lot easier to use AD Azure connect.
We use CRM 2013 which uses IFD, its not very clear from MS whether we can use anything but ADFS but could we retire ADFS and just use AD Azure connect with CRM IFD for authenticating external users to our on premise CRM?
Any advice would be most appreciated?
Ranjb81, I would suggest leveraging the Azure AD App Proxy model to integrate your on-prem SharePoint and potentially your on-prem CRM services to AzureAD for SSO when users are off network.
The short is that you can do this fairly easy with SharePoint as long as it is setup to accept Kerberos Authentication on-prem. I have setup this model several times and it works very well to publish SharePoint on-prem to the internet via the awesome Azure AD App Proxy framework.
For CRM, the IFD scenario really needs ADFS. In theory if you did not setup CRM using IFD, and just had it doing Kerberos as an "internal" type of setup, you could leverage the exact same framework via the Azure AD App Proxy components and publish it to the internet and integrate it to Azure AD for SSO and you would not need ADFS. This may have some other implications by not doing IFD though that I am not as familiar with.
Would be happy to help answer any questions on AAD App Proxy functionality if you are interested.
Can you let me know what claims rules you used? I am having a hard time configuring this part. It says you are suppose to pass the UPN/Name as the PrimarySID is optional. The issue with Name is it wants it in Company\Username format.
Hi, Are you talking about CRM IFD? If so - we were able to make it work by re-mapping "name" to "upn". There is no UPN field exposed on Azure, but the name field contains the UPN (firstname.lastname@example.org). This then allows the claims to proceed as per usual.
One further note - we did manage to make Outlook connect successfully, after realising OAUTH methods do not suffer the same home realm issues that the default claims methods do.
Update** Was able to sort out the Outlook CRM client so that it can connect using an Azure based AD service as authentication for an on-premise or partner hosted CRM. Ensuring that OAUTH methods are configured on CRM with the Claims setup (disabled by default) allows the newer CRM clients to connect without issue.
Business Applications communities