D365 Learnings - My Scrapbook | Kranthi Gullapalli

To keep this post short and simple. Trial instance which I created has MFA has been enabled  and while we are using the old method of login into XRMToolbox via Connection wizard, we are getting below error, as there is no possibility of a second level of authentication via Mobile. Below is stack trace and error encountered: Error : An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail. Stack Trace : Server stack trace: at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout) at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout) at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean onewa...

In one of my previous blog post , I've explained how to retrieve data from CRM to Portal using OData. OData is the simplest way to retrieve the list of CRM records to Portal, but if you are not aware of the do's and don'ts then you might need to face a tough consequence for that. If we read carefully the Microsoft documentation it says below: The OData feed that is published is anonymous and does not have any authorization checks; therefore, it is important not to enable oData feeds for data that is unsuitable for anonymous portal access. So there is no possibility of adding an additional mechanism of checking for the authenticated user or not from the portal end. To conclude: Do not expose any sensitive data via OData to the portal via Dynamics CRM with Entity List configuration. Where to use oData: In case if the data to be displayed on portal is not sensitive such as displaying list of products in an e-commerce website or having a blog feed etc. Alternate Solution for s...

Yes, you read it correctly, if you go with default CRM configuration for Email token you might land up in a big soup... and the more delay you do to fix the issue, it will cause you more pain to fix the issue thereafter. This article is having below sections: Understanding of Token structure Understanding of Issue Security breach scenario Possible solutions Section 1: Understanding of Token Structure: As per Microsoft documentation ( Link here ), below is the Token structure As can be seen above out of 7 digits, the first digit is a deployment tracking number, second is to identify the user, and third is the actual counter having the count related to the number of emails sent Below are definitions from Microsoft, referred from the same article above Deployment base tracking number Configurable from 0-2,147,483,647. Default value is 0. Can be used as an identifier for a specific instance, organization, or deployment of Microsoft Dynamics 365. User number digit rang...