locked
Claims Based Auth is my enemy - please help me defeat it RRS feed

  • Question

  • Hello All,

    I'm struggling with claims-based authentication. I've followed the instructions in Michael Guthmann's video so many times. I think the problem I'm having is as follows:

    1. We're using SAN certificates (necessary for us)
    2. CRM and ADFS are on the same server
    3. We have everything set up properly so ADFS is trying to authenticate requests, but it doesn't; we get the generic ADFS error screen. I believe this is because the Relying Party Trust is not getting the correct identifiers. We are supposed to have one URL each for the ORG, the EXTERNAL DOMAIN, and the DISCOVERY SERVICE. Our URLs here are:

    http://auth.domain.local/adfs/services/trust
    https://auth.domain.local/adfs/ls  
    https://auth.domain.local/adfs/services/trust/13/issuedtokenmixedasymmetricbase256
    http://auth.domain.local/adfs/services/trust/13/issuedtokenmixedsymmetricbase256
    https://auth.domain.local/adfs/services/trust/2005/issuedtokenmixedasymmetricbase256
    http://auth.domain.local/adfs/services/trust/2005/issuedtokenmixedsymmetricbase256

    The errors we get when we try to browse to the CRM website seem to indicate that our CRM URL needs to match the Relying Party's identifier (as I stated above, the identifiers are supposed to have the EXTERNAL DOMAIN URL as well as others), but the Relying Party Identifiers seem to just come directly from the name of the ADFS service, and can't be modified:

    •Error 1:
    The requested relying party trust 'https://org1.domain.com/default.aspx' is unspecified or unsupported. If a relying party trust was specified, it is possible that you do not have permission to access the trust relying party. Contact your administrator for details.

    •Error 2:
    A token request was received for a relying party identified by the key 'https://org1.domain.com/default.aspx', but the request could not be fulfilled because the key does not identify any known relying party trust.
    Key: https://org1.domain.com/default.aspx

    This request failed. 

    User Action
    If this key represents a URI for which a token should be issued, verify that its prefix matches the relying party trust that is configured in the AD FS configuration database.

    If anyone can help me understand why my relying party isn't setting up properly, I would appreciate it so much.

    Thanks!


    Blog: http://andrewbschultz.com @andrewbschultz
    Tuesday, March 22, 2011 10:20 PM

Answers

  • The issues was apparently this:

    If we had CRM installed on port 443, redirector file in IIS redirected to the wrong federationmetadata file. We had CRM on a different IP address than ADFS, on the same box. If CRM was on port 443, when we went to the URL for the federationmetadata (any of the URLs, either IP address or names with the location for the federationmetadata appended afterward), it sent us to the wrong federationmetadata.xml file. It sent us to the federationmedata.xml file that was on the ADFS website, which is much longer. If we put CRM on any port other than 443, when we browsed to the URL for the federationmetadata, we got the right file.

    Because the federationmetadata was wrong, when we went to set up a relying party in ADFS, and put in the URL for the federationmetadata, it got the wrong file, and obviously then the relying party was messed up.

    Obviously a bug, but hopefully this will help someone else with the same problem!


    Blog: http://andrewbschultz.com @andrewbschultz
    Thursday, April 14, 2011 9:54 PM

All replies

  • Anyone? Matios?!
    Blog: http://andrewbschultz.com @andrewbschultz
    Friday, March 25, 2011 5:05 PM
  • Nobody has any insight on this?
    Blog: http://andrewbschultz.com @andrewbschultz
    Monday, March 28, 2011 5:32 PM
  • Sounds like it might be time for a Microsoft support case.
    Phil Edry – Altriva Solutions – http://www.altriva.com/AltrivaBlog.aspx
    Monday, March 28, 2011 5:34 PM
  • Andrew

    It seems that your relying parties are not configured correctly.  The metadata URL should end in "/federationmetadata/2007-06/federationmetadata.xml" and start with either the internal web address (https://CRM_server:port_number/federationmetadata/2007-06/federationmetadata.xml) or the external web server address set in deployment manger (https://auth.domain.com:port_number/federationmetadata/2007-06/federationmetadata.xml)

    Event Viewer -> Applications and Services Logs -> AD FS 2.0 is a good source for error messages


    Marc Collins www.QGate.co.uk
    Tuesday, March 29, 2011 11:52 AM
  • Hi Marc,

    That's what we've got. It won't let you enter a metadata URL that doesn't point to the federationmetadata.xml file, if I remember correctly. We've tried every possible permutation of web addresses that reach the federation metadata. The metadata seems to generate the relying party's identifiers, and it's not generating the correct ones. We think it's some combination of the fact that we have SAN certificates, 2 IP addresses on the same box (one for ADFS and one for CRM), or something else we don't understand.


    Blog: http://andrewbschultz.com @andrewbschultz
    Tuesday, March 29, 2011 3:17 PM
  • Instead of using 2 IP addresses, you should use ports to seperate the 2 websites.  (ADFS:443, CRM:555 for example). 

    Your SAN should have a subject matching your internal URL (CRM_SERVER_NAME) and a subject that has a wildcard (*.domain.com).  You CRM appPool must also have read permissions for this certificate.

    Can you browse to the differnet endpoints in IE successfully? Any certificate warnings or login promts will stop all from working.


    Marc Collins www.QGate.co.uk
    Tuesday, March 29, 2011 4:12 PM
  • The issues was apparently this:

    If we had CRM installed on port 443, redirector file in IIS redirected to the wrong federationmetadata file. We had CRM on a different IP address than ADFS, on the same box. If CRM was on port 443, when we went to the URL for the federationmetadata (any of the URLs, either IP address or names with the location for the federationmetadata appended afterward), it sent us to the wrong federationmetadata.xml file. It sent us to the federationmedata.xml file that was on the ADFS website, which is much longer. If we put CRM on any port other than 443, when we browsed to the URL for the federationmetadata, we got the right file.

    Because the federationmetadata was wrong, when we went to set up a relying party in ADFS, and put in the URL for the federationmetadata, it got the wrong file, and obviously then the relying party was messed up.

    Obviously a bug, but hopefully this will help someone else with the same problem!


    Blog: http://andrewbschultz.com @andrewbschultz
    Thursday, April 14, 2011 9:54 PM
  • I'm running into a similar issue where we have ADFS and CRM on two seperate boxes with different external and internal IPs and both on port 443. The external federationmetadata would be used internally under this config, so we had to move the CRM port to 444, which is not ideal for good looking URLs. I've started a case with Microsoft to confirm this is a bug, or if there is a known workaround.

    Andrew -- thanks for posting your resolution here!
    Phil


    Phil Edry – Altriva Solutions – http://www.altriva.com/AltrivaBlog.aspx
    Wednesday, July 13, 2011 7:45 AM
  • Has anyone found a work-around for this?  I would like to use two different IP addresses so that we can use the standard 443 port for both our CRM web application and Federation Services.  Using a non-standard port is not acceptable because it would cause firewall configuration issues.  (Both of these solutions are on the same server).
    Monday, October 24, 2011 7:34 AM
  • Thanks Andrew.  I've just been through a similar thing.  I though I was being really clever by co-locating ADFS and CRM on the same Server and using host headers to direct traffic to the correct site.  If CRM is on 443 then I do get the same problem as you where it downloads the wrong metadata.  This happens EVEN if I stop the default web site.  It must be some sort of http handler thing listens on 443 /federationmetadata and doesn't care about host names.  This is a bit like Reporting Services in 2008 but that has a configuration tool to specify what names you want.  Clearly this is missing from ADFS 2.0.

    Anyway, I added an extra binding to my CRM site, used that to downlaod the correct metadata.  Even if I  then removed the binding Claims signon still works.

    Thursday, January 26, 2012 1:01 PM
  • Hello We are facing the same issue. We have ADFS on one server and CRM on a different. When we try to browse our metadata site for crm.company.com we have to put /organization to be able to browse successfully.

    Does the internal CRM have to be on a different port? Andrew you said you added binding. We tried to use https 443 and added https 444 and still do not get it to pull proper metadata. The external will work but the internal will continually prompt for password or lead to the adfs site.

    Any help is appreciated

    Thursday, March 1, 2012 5:11 AM
  • Hi,

    We are also facing the same problem since we are maintianing ADFS & CRM 2011 in different servers.

    My URLs are link this HTTPS://ADFS.COMPANY.COM and HTTPS://CRM.COMPANY.COM:5555/

    I had verified the permission to read the SSL certificate for CRM APPPOOL account (network service)

    Also, the Metadata URl for ADFS is running without any certificate errors.

    The ADFS trace log (debug) shows this error,

    Failed to process returned scope with error:
    MSIS3055: The requested relying party trust 'https://crm.company.com:5555/' is unspecified or unsupported. If a relying party trust was specified, it is possible the user does not have permission to access the relying party trust.

    Plesae help me to resolve this ASAP.

    Thanks,
    Saravanan


    Saturday, March 10, 2012 8:14 PM
  • Failed to process returned scope with error:
    MSIS3055: The requested relying party trust 'https://crm.company.com:5555/' is unspecified or unsupported. If a relying party trust was specified, it is possible the user does not have permission to access the relying party trust.

    with the above error message it seems some where we are specifiying incorrect URL.

    Could you check the federation metadats URLs in relying party trust in ADFS management console.

    Also, go to deployment manager -> right click -> properties -> web address tab -> and confirm if you have specified the internal CRM URL with correct port number for which we are configuring claims.


    Arpita

    Tuesday, March 13, 2012 1:57 AM