locked
Authenticating and Authorization error with Dynamics Online RRS feed

  • Question

  • To whomever can help,

    For a project at work, we are sending SOAP requests from our Java framework to the SOAP endpoints (of the form "https://{organization}.api.crm.dynamics.com/XRMServices/2011/Organization.svc").  We are authenticating and getting security tokens from https://login.live.com/liveidSTS.srf.  This all seemed to be working fine until recently.  It appears that any new provisioned organization recently does not seem to be working.  For new instances, we seem to get the following error when trying to hit the endpoint: 

    ID3242: The security token could not be authenticated or authorized.

    For older instances, it seems to still work.  And it is not the case of a bad username or password because it seems to return a different error message if that is the case, claiming invalid username or password.  Has something changed in Dynamics recently?  Any help would be very much apprecaited.

    Thank you,

    Ryan

    Wednesday, June 13, 2012 5:30 PM

Answers

  • Ryan,
    What type of authentication is the organization using? Are you sure that it is using Live ID (as Pat has mentioned)? If you are unsure, you can actually find this information from the Organization.svc's WSDL (append ?wsdl=wsdl0).

    Michael

    • Marked as answer by Ryan H Lo Tuesday, June 19, 2012 6:55 PM
    Friday, June 15, 2012 7:13 PM

All replies

  • Are your new orgs in different geographical regions? The servers you need to talk to for CRM Online can be different for US vs. Asia vs. Europe, for example. Check the following link for details.

    https://community.dynamics.com/product/crm/crmtechnical/b/crmgirishraja/archive/2011/03/22/crm-online-2011-web-services-soap-sample-now-ready-for-europe-amp-asia.aspx

    Thursday, June 14, 2012 7:46 PM
  • The orgs are still in crm.dynamics.com.  When I log into the new orgs, "crm" is still in the URL as opposed to "crm4" or "crm5".  So I do not believe that is the issue.  The handshaking is the same as before.  It registers the device, and then there are two more exchanges with liveidSTS.srf to get the tokens.  The tokens retrieved appear to be legit.  However, when executing a retrievemultiple request for entitees, I get that ID3242 error mentioned before.  The same code seems to work for organizations created about a month ago.  But any new instance provisions seem to cause the identified error.  Quite frustrating because it is virtually a black box to me.  The same code seems to work for older server provisions, but no longer works for instances provisioned currently.

    Friday, June 15, 2012 12:06 AM
  • By chance were your new organizations created using the O365 subscription platform?  Because they use a different authentication provider (O365's service 'OrgId', instead of Windows Live ID).  Otherwise, your same LiveID authentication techniques should still work...

    -Pat

    Friday, June 15, 2012 6:59 PM
  • Ryan,
    What type of authentication is the organization using? Are you sure that it is using Live ID (as Pat has mentioned)? If you are unsure, you can actually find this information from the Organization.svc's WSDL (append ?wsdl=wsdl0).

    Michael

    • Marked as answer by Ryan H Lo Tuesday, June 19, 2012 6:55 PM
    Friday, June 15, 2012 7:13 PM
  • Pat/Michael,

    We're definitely using Live ID (double checked per Michael's suggestion).  I'll look a little closer to see if I can find any subtle differences.  I'm using the same Live ID.  Going against instances provisioned a month ago or even before seems to work fine, but any newly provisioned instance doesn't seem to work.  Our java based SOAP calls are based on the SOAP only client that Girish Raja provided to the community.  Is there any existing detailed documentation for using these web service endpoints?  All the sample code is typically .Net (C# or VB) samples.  It's difficult to figure out what to do considering a lot of the details are abstracted away by the .Net assemblies.  If we can't use .Net, where can we go for more details on authenticating against and using the Dynamics web service endpoints?  If you are open to contacting me directly or allowing me to contact you directly by any means, please let me know.

    Thank you,

    Ryan

    Friday, June 15, 2012 9:05 PM
  • Unfortunately, we don't have samples for Java to connect to CRM.

    That said, are you using the discovery service?

    Michael

    Friday, June 15, 2012 10:50 PM
  • We are using the Discovery Service to get the Organization.svc URL.  Should we be doing more than that?

    Ryan

    Monday, June 18, 2012 4:52 PM
  • Using the Discovery Service is the correct approach. However, you cannot share the token generated for the Discovery Service with the Organization Service. If you do, you will see this error. Instead, you have to generate a token once for the Discovery Service and once for the Organization Service. You can share the Device Token between the two of them.

    Michael

    Monday, June 18, 2012 5:28 PM
  • Michael,

    Thank you for your help.  I eventually found the problem based on a suggestion of yours above.  Even though it didn't directly answer my problem, it led me to find it.  It turned out there was a detail in the wsdl that I needed in order to form the security request properly.  In particular, the following information was needed:

    <ms-xrm:AppliesTo>urn:crmna:dynamics.com</ms-xrm:AppliesTo>

    Thanks again,

    Ryan

    Tuesday, June 19, 2012 7:00 PM
  • We are also facing the same problem can you explain to which message in the SOAP handshake you see this problem? We are also using Java to connect to MSD.

    Thursday, June 21, 2012 11:27 AM
  • As mentioned above, you will want to get that information from the wsdl for your service endpoint.  For instance, you will want to do an http get to <a href="https://.api.dynamics.com/XRMServices/2011/Organization.svc?wsdl=wsdl0">https://<organization>.api.dynamics.com/XRMServices/2011/Organization.svc?wsdl=wsdl0 to get back the wsdl info.  Parse that information to get "AppliesTo" tag mentioned above.  You'll want that value to be used later in the authentication hand-shaking process.  In particular, for the last step of getting the final tokens, you'll see something like the following psuedo-xpath in the SOAP body of the request:  //RequestSecurityToken/AppliesTo//Address.  It is for this value that you will want to put in the value you looked up in the wsdl.  This has apparently changed recently.  And it appears that this has to be dynamic because depending on when your organization instance was provisioned, this could be different (i.e. it could be either "urn:crmna:dynamics.com" or "urn:crm:dynamics.com").  I hope that helps.

    Monday, June 25, 2012 5:00 PM