2

I'm hoping someone can help me out as this has been puzzling me for quite some time now. I have a domain controller set up with kerberos armoring enabled to include claims in the issued kerberos tickets. I then have Dynamic Access Control configured to define some claim types to include in the kerberos tickets. The kerberos tickets appear to contain the defined claim types when I tested using a simple PowerShell script using System.Security.Principal.WindowsIdentity to query all claims included in the current user's Identity, which I presume is obtained from the existing issued kerberos ticket.

I then configured Active Directory Federation Services which integrated with Active Directory DC as a Claims Provider Trust, and I setup a SAML test web application to server as a Service Provider / Relying Party. The setup works if I use "Send LDAP Attribute as Claims" in the Relying Party trust to query AD and obtain the claims.

However, what I wanted to do is get the claims included in the kerberos tickets and include them in the SAML token issued by AD FS as the user performs SSO through Windows Integrated Login. I tried all possible "Pass Through" rules in both Claims Provider Trust and Relying Party Trust to extract these claims from he kerberos tickets and include them in the generated SAML tokens in AD FS, but none seem to work. I even created a custom rule to just pass through all claims but none seem to work. It appears that the kerberos tickets don't even contain the associated claims I defined in Dynamic Access Control since I was able to pass through default claims in kerberos like the UPN, Groups SID, Name, etc. But if it's the custom claims I defined in Dynamic Access Control to be included in the kerberos ticket, they seem to be nonexistent. Can anyone help me diagnose this further?

FYI, the test web app I used is simpleSAMLphp and I just use it to displays all claims/attributes it receives from the SAML token issued by AD FS.

Here is the PS script I used to test and see that the kerberos ticket of the current user contains the claim types I defined in Dynamic Access Control:

$CurrentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent()

$Username = $CurrentUser.Name
Write-Output "User: $Username`n"
Write-Output "---- CLAIMS ----`n"
$Claims = $CurrentUser.Claims

foreach ($claim in $Claims) {
    # Get Claim Type
    if ($claim.Type -match "http://") {
        $claimType = ($claim.Type).Split('/')[($claim.Type).Split('/').Count -1]
    }
    elseif ($claim.Type -match "ad://") {
        $claimTypeName = ($claim.Type).Split(':')[($claim.Type).Split(':').Count -2]
        $claimType = $claimTypeName.Split('/')[$claimTypeName.Split('/').Count -1]
    }
    # Transform
    if ($claimType -eq "groupsid") {
        $claimType = "group"
    }

    # Get Claim Value
    $claimValue = $claim.Value
    if ($claimValue -match "S-" -and $claimType -eq "group") {
        try {
            $SIDvalue = New-Object System.Security.Principal.SecurityIdentifier($claimValue)
            $accountName = $SIDvalue.Translate([System.Security.Principal.NTAccount])
            $claimValue = $accountName
        }
        catch {
            Write-Verbose "WARNING: Unable to get group name attribute of SID $SIDvalue"
            $claimType = "groupsid"
        }
    }
    Write-Output "$claimType`: $claimValue" 
}

If I can provide any other information to help diagnose this issue, please let me know.

Thank you in advance.

psApprentice
  • 23
  • 2
  • 7
  • And just to add, I am using AD FS 3.0 on Server 2012 R2, so reading kerberos claims from Claims Provider (AD DS) should be supported. As mentioned, kerboros armoring is enabled with "always provide claims" on the DCs and all client computers are configured to enable kerberos armoring/compound authentication. – psApprentice Jan 29 '16 at 21:39

0 Answers0