I ran into this issue really recently working at a client with a new, pretty basic ADFS environment that was acting as the identity provider, through an ADFS proxy server relay. I couldn’t wrap my head around why it wasn’t working, the groups themselves were resolving correctly, and even showing up in the identity data sources in the people picker. However, members of the AD securitygroup, (NOT the SharePoint group) were still being denied access to the SharePoint site.
To fix this issue follow these steps:
- Open the federation server box.
- Open the ADFS management console.
- Edit the claim rules for the relaying party trust
- Select the tab Issuance Transform Rules
- Edit the Send LDAP Attributes as Claims
- This should have:
- Claim Rule Name : Pass-through LDAP Claims
- Attribute Store : Active Directory
- Set: Token Groups unqualified names (Don’t Use: Token Groups – Qualified by domain name) | Outgoing ClaimType: Role
- Set: User-Principal-Name | Outgoing Claim Type : UPN
- Open the SharePoint management shell, run the following PowerShell script to create the issuer. If you have an issuer already made, remove it or execute the coordinating update commands. Make sure you replace the $certPath, $realm, and any of the string literals within $ap.
$certPath = your certification path
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“$certPath”)
$map1 = New-SPClaimTypeMapping “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming
$map2 = New-SPClaimTypeMapping “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname” -IncomingClaimTypeDisplayName “Login” â€“SameAsIncoming
$map3 = New-SPClaimTypeMapping “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” -IncomingClaimTypeDisplayName “Role” â€“SameAsIncoming
$map4 = New-SPClaimTypeMapping “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn” -IncomingClaimTypeDisplayName “Account ID” â€“SameAsIncoming
$realm = “urn:” + $env:ComputerName + “:adfs”
$signinurl = “https://yoursigninurl”
$ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS” -Description ADFS 2.0 -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1, $map2, $map3, $map4 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType
If you are curious about the way to update, rather than create a new issuer, you can use the following. In the above, you may or may not need all those assertion mappings depending on how your trusted relay issuance rule setup:
$issuer = Get-SPTrustedIdentityTokenIssuer
$map=New-SPClaimTypeMapping “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” -IncomingClaimTypeDisplayName “Role” â€“SameAsIncoming
Now you HAVE to apply KB hotfix 2536591 located here: http://support.microsoft.com/kb/2536591/en-us
Boom! Groups will work.
There are several steps involved in the process of deploying cross farm services. Each step is very important to gain the overall results you are after.
Configuration of trusted farms ensures all of the farms that use exchanges can trust each other. Certificates have to be exported to a file. Make sure you back up that file before you connect to any of the cross farm services. Publishing service applications must be done before you will be able to successfully share it across farms. Connecting cross farm service applications provides a connection must be made to a service that is published by a remote farm. This will require the URL to be entered of the published service. This is going to be displayed when you publish it. The connection on the local farm has to be created so that it can be connected successfully to a service application for a remote farm.
Should there be two domains where the server farms are located, the User profile service application will require both of them to trust each other. With the Business Data Connectivity and Secure Store Service the domain of the publishing farm has to trust that of the consuming farm. None of the cross farm service applications are going to work if there isn’t a trust requirement in place for the two domains.
It is possible for certain service applications to access external data sources. This occurs through the access of a delegated Windows identity that will place some additional requirements on a given environment. These types of service applications have to be in the same domain as the SharePoint Server 2010 farm. This is where the service applications are housed. The other option is for the service application to be configured using the Secure Store Service.There are plenty of different service applications that can be found across the external data. They use a delegated Window identity. This includes:
- Excel Services
- InfoPath Forms Services
- PerformancePoint Services
- Visio Services
The service applications used to access external data sources must have a delegated Windows identity. Otherwise it has to be configured for the use of the Secure Store Service. This will store and maintain the credentials of a user or a service. When service applications are used to store credentials, they have to be authenticated before the data can be accessed.
If the external data sources aren’t within the same domain then authentication for the external data sources will fail unless you use the Secure Store Service. Farm servers can be split between two different domains but the application servers have to be found in the same domain as the external data sources.
There are several service applications and products that don’t have those requirements. They include:
- Access Services
- Business Data connectivity Services
- Microsoft Business Connectivity Services
- Microsoft Project Server 2010
- Microsoft SQL Server PowerPivot for Microsoft SharePoint
- Microsoft SQL Server Reporting Services