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.
You will find that the federated identity has a very flexible structure to it. With that in mind, Adam Buenz’s Software House is able to add customers when they have a trust relationship in place by the issuer and they create claims mapping. This is all very simple behind the scenes action due to the process of such mapping being a very simple process. However, it is also important to realize here that the actual software component order application didn’t change at all. When you create a federation there is only some minor changes to that overall structure that need to be taken care of.
With the claims of ARB Security Solutions the ability to read the name of the business and the name of the employees is there. There won’t be any mix ups when it comes to finding out who accessed the application from Adam Buenz’s Software House and who accessed it from ARB Security Solutions. As a result there is less upkeep involved with federated identity. The accounts don’t need to be copied and maintained even though there are many security realms associated with them.
However, there are some limitations in place to be aware of. First, the way in which the claims mapping works has to be evaluated. Anyone that is with ARB Security Solutions is able to track software component orders due to the way in which the requests are set up with the type role and the value of software component order tracker in place. What you should do though is limit exactly who in the business will have access. That is what we will take a closer look at.
It is vital that you are able to set up trust relationships. In this scenario the two entities are using ADFS 2.0 for the issuer of their security tokens. A public key certificate needs to be in place. This will be in a file that the administrators from ARB Security Solutions will send to Adam Buenz’s Software House. It is as easy as attaching it to an email and sending.
The administrators for ARB Security Solutions will configure ADFS so that they requests from the Adam Buenz’s Software House issuer will be accepted. All that needs to be done for this to occur is to select TBD menu in the ADFS. The Adam Buenz’s Software House administration will install the certificate on the ADFS host. This allows the federation to work with both issuers.