locked
Custom pages (mine or 3rd party) not authenticating with CRM. CRM Configuration issue? RRS feed

  • Question

  • I'm struggling with a CRM configuration issue that I cannot seem to resolve.  Initially I believed it to be something wrong with my code, but now I am looking at the CRM configuration itself. This post describes where I first encountered the issue, and some of the symptoms. The main takeaway was that the discovery service was returning the following:

    orgname.site.com/MSCRMServices/2007/CrmService.asmx
    instead of  hostname:5555/MSCRMServices/2007/CrmService.asmx

    I got around it by hard-coding the hostname instead of the FQDN, ignoring what the discovery service returned.  

    Next, I tried to install a third-party add-on, comprised of a plug-in and a custom webpage.  The plugin works fine, the page only works from directly on the CRM server.  Accessing from anywhere else throws up an authentication error when looking at the trace.  Neither SPLA nor AD authentication would succeed.  Making changes from the server, the changes are reflected by the plugin from off of the server, so the webpage authentication is to blame.  Again.

    This leads me to believe that there is something non-standard about how CRM was configured.

    Here is how CRM / IFD was configured:   

     

    ·         ASP.Net Security Account:
    
    o   Domain\crmservices
    
    o   After install we created the SPN for the account using the netbios name and FQDN
    IFD

     

    Using the IFD we setup the system to be a Internet Facing Only Deployment.
    
    o   IP address is  set to the server’s IP: #.#.#.#
    
    o   IFD App Root Domain: corporate.company.com (http)
    
    o   AD App Root Domain: corporate.company.com (http)
    The domain being used for our servers is corporate.company.com, which is part of the FQDN used to access the site.  The IFD can be reached at orgname.corporate.company.com.  I believe this was set in DNS, for orgname.corporate.company.com to point to the development server.  There is also a production CRM machine on the network, with a different org name, which again I believe might be hard-coded in DNS.  The DNS stuff is just speculation, I don't have direct access to the IT company's DNS information.

    Does anyone have any idea of what could be causing this?  

    Thanks,
    Ahren

    Update: At the request of the add-on creator, I tried to hit the server using the FQDN from itself,  http://orgname.corporate.company.com.  This resulted in a HTTP 401 error when I tried to log in.  Also, in the registry the SKU is OnPremise.  Does that impact anything in CRM, or is it a residual item from the initial installation?
    • Edited by apfrehm Wednesday, January 13, 2010 4:05 PM Additional information
    Wednesday, January 13, 2010 3:55 AM