$realm = "urn:sharepoint:collab"
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS v2" -Description "ADFS v2" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl "https://urlToYourAdfsServer/adfs/ls" -IdentifierClaim http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Thanks for this information, now I am trying a scenario where I have multiple site collections under one single application ? Do you have any idea/suggestion on how this could be done ?
Thanks for sharing this article.Its very good.My problem is i have two sites which can be accessed by same sts provider but i am not able to access one site from another.Can you please tell how to do that.You can reply me: firstname.lastname@example.org. I would really appreciate.
same question as Marcio. how to enable provider realms on a site collection basis ? we have host-based site collections.
Thanks for all the great articles, Steve! They have helped me a great deal! Keep it up!
I am also trying to achieve the same to have two SharePoint web application in same server and m trying to configure it with one ADFS server. I tried your commands
$uri = new-object System.Uri("https://mysites")
after executing second line i a getting below error message:
You cannot call a method on a null-valued expression.
At line:1 char:23
+ $ap.ProviderRealms.Add <<<< ($uri, "urn:sharepoint:harmony")
+ CategoryInfo : InvalidOperation: (Add:String) , RuntimeExcept
+ FullyQualifiedErrorId : InvokeMethodOnNull
i am having same issue, can someone help me
I have try this way,there isn’t a way to say this token signing cert should be used with this relying party, so you really need to find a way to make it work with the single cert. the target is our prouct <a href="www.cfl4u.com/.../75A-industrial-fan.html">industrial fan</a>,But no useless.
Thank you for this article.
I have one problem after completing described steps.
When I log into my sites application, I get an error HTTP 405 "Method not allowed" and the page URL is https://<webappname>/_trust
Do you have any ideas why?
Thank you in advance.
I have found the solution.
The problem only occurs when both web application share the same host address with different ports.
In this case web apps share authorization token in the same cookie. It makes authorization at the first app to be invalid for the second one.
So, the solution is here:
Each SharePoint web application must have its own FedAuth cookie if it is to function correctly in an single sign-on environment. In a production environment, this is not normally an issue because each SharePoint web application has a separate host name: for example, a-portal.adatum.com, and a-techs.adatum.com. However, in a lab environment you may not want to configure the necessary DNS infrastructure to support this; if your SharePoint web applications share the same host name, for example lab-sp.adatum.com:31242 and lab-sp.adatum.com:40197, then you must make a configuration change to make sure that each application uses a different name for the FedAuth cookie. You can change the name of the FedAuth cookie in the microsoft.IdentityModel section of the Web.config file. The following snippet shows how to change the token name to "techsFedAuth" from its default name of "FedAuth."
<cookieHandler mode="Custom" path="/" name="techsFedAuth">
Do you know if there is a similar option for Forms Based Authentication? I know the FedAuth cookie for Forms based auth includes the URL it applies to. Is there a way to setup a trust to allow mulitple sub domains with forms?
I'm trying to allow a single sign on between two web apps using Claims/Forms:
Most articles I've found apply to SP 2007 only and suggest to sync machine keys.
@Ivan Gorbadei: You saved my life, you know. Thanks a lot for your information. Hope you can see that.
Didn't work for me. Running SP2013, $uri.ProviderRealms.Add gives error You cannot call a method on a null valued expression. It seems $uri does not have a ProviderRealms property.
Well I found my problem, I already had a provider setup so I didn't run the first bit of the code, so $ap as not defined. I was missing a line of code. Hope it helps someone.
Need to run:
$ap = Get-SPTrustedIdentityTokenIssuer -Identity "ADFS v2"
$uri = new-object System.Uri("https://mysites")
I finally figured out this actually seems to be the correct way to allow *multiple* active directory tenants access into a single web application, such as each tenant has a corresponding (host-named) site collection in that web application. Basically you
configure ACS to have a Identity Provider for each tenant and a matching Relying Third Party application that corresponds to the site collection address each tenant uses, then for each tenant add a mapping between the site URL and the realm URN (I just make
the same actually) using the technique you mention here, and voila, between SharePoint and ACS magically seem to work out between them that there's only a single suitable Identity Provider for the address that the user has accessed, and logs them in with the
correct credentials (potentially redirecting them to the correct login page first if required).