none
how is the realm you use for the trusted ID provider associated with sharepoint

    Question

  • I'm setting up a new trusted provider with ADFS I am only importing 1 claim (emailaddress) and setting the default claim so that i can take advantage of Convert-SPWebApplication and not be required to use Move-SPUser. 

    I used the below PowerShell to implement. The realm I used is arbitrary and means nothing. I could not find anything that said "hey this realm should literally come from your SP instance." 

    Is the realm something I need to get from the farm, and if so, how do I get it?

    $realm = “urn:sharepoint:portal”
    $signInURL = “https://signinURL"
    $certficateLocation = “C:\ADFS_Signing.cer”
    $rootCertificate = Get-PfxCertificate $certficateLocation
    New-SPTrustedRootAuthority -Name “ADFS Token Signing Cert” -Certificate $rootCertificate
    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certficateLocation)

    $ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $realm -ImportTrustCertificate $cert -SignInUrl $signInURL -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $realm 

     

    I have no issues in PowerShell, UPS looks good, it seems as though SharePoint likes what i've done. Until i go to login. Then I get the error below "The issuer of the token is not a trusted issuer."
    The issuer of the token is not a trusted issuer.

    NOTES:

    • The thumbprints match.
    • I'm ADFS is pulling emailaddress
    • I'm using EMAIL as my default claim.
    • UPS is syncing
    • UPS Managed properties are set to 
      -Claim User Identifier: mail
      -Claim Provider Identifier: ADFS 
      -Claim Provider Type: Trusted
    • all is happy in SharePoint land until i try to login


    Wednesday, April 19, 2017 5:56 PM

Answers

All replies

  • I have noticed that "DefaultProviderRealm" and "RegisteredIssuerName" are the same.

    Should this be the case?

    --Grasping at straws here.

    --POWERSHELL OUTPUT FOR Get-SPTrustedIdentityTokenIssuer--

    ProviderSignOutUri          : 
    DefaultProviderRealm      : urn:sharepoint:portal
    ProviderRealms               : {}
    ClaimTypes                     : {http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname, http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid, 
                                    http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress...}
    HasClaimTypeInformation: True
    ClaimTypeInformation      : {Email, User Name, User SID, Security Group...}
    ClaimProviderName          : ADFS SAML Default Claim
    UseWReplyParameter       : False
    UseWHomeRealmParameter: False
    GroupClaimType                : 
    RegisteredIssuerName       : urn:sharepoint:portal
    IdentityClaimTypeInformation  : Microsoft.SharePoint.Administration.Claims.SPTrustedClaimTypeInformation
    Description                   : ADFS SAML Default Claim
    SigningCertificate            : [Subject]

     
    Wednesday, April 19, 2017 6:39 PM
  • Hi SharePoint AU,

    Please review your steps to configure AD FS with SharePoint 2013, follow the steps in the article below:

    https://blogit.create.pt/miguelmoreno/2014/11/14/configure-adfs-3-0-with-sharepoint-2013/

    https://technet.microsoft.com/en-us/library/hh305235.aspx

    Check if you set the reply part trust identifies correctly which format is https://<sharepoint server FQDN>/_trust/

    Besides, "DefaultProviderRealm" and "RegisteredIssuerName" are the same, because you set the RegisterIssuerName as Realm when you add new SPTrustedIdentityTokenIssuer, it might have no impact for your issue.

    Best regards,

    Grace Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, April 20, 2017 10:43 AM