Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Federation Trusts’ Category

(2017-06-12) Changing The Identity Type Displayed On The MFA Page In ADFS

Posted by Jorge on 2017-06-12


By default when you hit the MFA page in ADFS 2012 R2, the identity type displayed is similar to DOMAIN\SAMACCOUNTNAME as you can see in figure 1 below. The MFA page in ADFS 2012 R2 by default uses the value from the name claim type (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name”) to display that same value in the MFA page in ADFS 2012 R2.

The name claim type is configured by default in an Acceptance Transform Rule on the “Active Directory” CP trust, and it is most likely read from the “msDS-PrincipalName” attribute in AD.

The Acceptance Transform Rule on the “Active Directory” CP trust for the name claim type may be similar to

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through all Name claims"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c);

image

Figure 1: MFA Page In ADFS 2012 R2 With The Default Value For The Name Claim Type

However, with all the cloud development going on and everything focusing on the mail address of a user instead, you may want to display the mail address of the user instead as displayed in figure 2 below.

To make this change you need to delete the default Acceptance Transform Rule on the “Active Directory” CP trust for the name claim type and create a new rule where you will flow the value of the mail claim value (MAIL@ADDRESS.COM) into the name claim type. The new Acceptance Transform Rule on the “Active Directory” CP trust would look like:

@RuleTemplate = "MapClaims"
@RuleName = "E-mail Address To Name"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

image

Figure 2: MFA Page In ADFS 2012 R2 With The Custom Value For The Name Claim Type

Is there a catch to this? Yes there is, or better yes there are!

[Catch 1]

By default the e-mail address is NOT extracted from AD by ADFS! Because of that you need to create your own Acceptance Transform Rule where you do that. The Acceptance Transform Rule you need at least is or looks similar to:

@RuleTemplate = "LdapClaims"
@RuleName = "E-mail Address"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"), query = ";mail;{0}", param = c.Value);

Because the name claim type depends on this Acceptance Transform Rule, this Acceptance Transform Rule for the mail claim type must be processed before the Acceptance Transform Rule for the name claim type

[Catch 2]

Some applications connected to ADFS may expect to receive a name claim value that looks like DOMAIN\SAMACCOUNTNAME instead of MAIL@ADDRESS.COM. By implementing the new Acceptance Transform Rule for the name claim type you will impact those applications.

To mitigate that impact before making those changes, you would need reconfigure the RP trust of the application that needs the name claim value. If RP trust has an Issuance Transform Rule that is similar to or looks like:

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through all Name claims"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"%5D => issue(claim = c);

….you would need to delete that Issuance Transform Rule and replace it with:

@RuleTemplate = "MapClaims"
@RuleName = "Windows Account Name To Name"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

[Catch 3]

By default when you hit the MFA page in ADFS 2016, the identity type displayed is similar to UPN@ADDRESS.COM as you can see in figure 1 below. The MFA page in ADFS 2016 by default uses the value from the upn claim type (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”) to display that same value in the MFA page in ADFS 2016. However, if there is no value for the upn claim, it will fall back to the value of the name claim. Unless you have removed it, by default ADFS has an Acceptance Transform Rule on the “Active Directory” CP trust for the upn claim type. And if you look carefully, the text also changed (compare figure 1 and figure 3).

As you can see in figure 3, it now really shows my upn (jorge@iamtec.net) whereas mail e-mail address uses a different suffix (jorge@iamtec.nl). With the use of Azure AD, the federated/managed domain in AAD is iamtec.nl and not iamtec.net.

image

Figure 3: MFA Page In ADFS 2016 With The Default Value For The UPN Claim Type

To be able to logon with the mail address I have 2 options, either update the userPrincipalName value to match the mail address value in AD or keep it as is and use the alternate logon ID feature in ADFS to target the mail address field in AD. If you choose the first option the value in the MFA page is also updated automatically and you do not need to update Acceptance Transform Rules. If you choose the second option you may need to delete the default Acceptance Transform Rule for the upn claim type and replace it with the following Acceptance Transform Rule:

@RuleTemplate = "MapClaims"
@RuleName = "E-Mail Address To UPN"

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

This new Acceptance Transform Rule for the upn claim type would result in the following for on the MFA page in ADFS 2016

image

Figure 4: MFA Page In ADFS 2016 With The Custom Value For The UPN Claim Type

Is there a catch to the catch? Unfortunately there is! As mentioned earlier for the name claim type, the same would apply to the upn clam type. Some applications connected to ADFS may expect to receive a upn claim value that looks like UPN@ADDRESS.COM instead of MAIL@ADDRESS.COM. By implementing a new Acceptance Transform Rule for the upn claim type you will impact those applications.

To mitigate that impact before making those changes, you would need reconfigure the “Active Directory” CP trust and implement an Acceptance Transform Rule that is similar to or looks like:

@RuleTemplate = "MapClaims"
@RuleName = "Original UPN To Custom UPN Claim"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D
=> issue(Type = "
http://temp.org/identity/claims/orgUPN", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

…and you would need reconfigure the RP trust of the application that needs the original upn claim value. If RP trust has an Issuance Transform Rule that is similar to or looks like:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D
=> issue(claim = c);

….you would need to delete that Issuance Transform Rule and replace it with:

@RuleTemplate = "MapClaims"
@RuleName = "Custom UPN Claim To Original UPN"
c:[Type == "http://temp.org/identity/claims/orgUPN""http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

Cheers,
Jorge

 

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Claim Types, Claims, Claims Rule Language, Federation Trusts | Leave a Comment »

(2014-10-01) TroubleShooting Federation/SSO To Windows Azure AD And Office 365

Posted by Jorge on 2014-10-01


When setting up DirSync And Federation between your on-premise AD and Windows Azure AD to support identity sync and SSO, the most important attribute to make sure everything works are the immutableID and the userPrincipalName.

Paul Williams from msresource.net has written a great number of blog posts about this, touching all kinds of related stuff. See the following blog posts:

With regards to the implementation I used the string version of the objectGUID (AD) as the immutableID (sourceAnchor in AAD)) and the UPN as the userPrincipalName (AAD). I achieved that by leveraging FIM with the AAD connector. Because of that I also had to implement slighty different claims rules in ADFS for Azure AD/Office 365. The rules in my ADFS v2.0 looked like:

@RuleName = "Identity Claims – objectGUID (Base64) To objectGUID (String)"
c:[Type == "
http://temp.org/identity/claims/adObjectGuidBase64org"]
=> add(store = "String Processing Store", types = ("http://temp.org/identity/claims/adObjectGuidString"), query = "fromBase64GuidtoStringGuid", param = c.Value);

@RuleName = "Identity Claims – upn To UPN"
c:[Type == "
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN", Value = c.Value);

@RuleName = "Identity Claims – objectGUID (String) To ImmutableID"
c:[Type == "
http://temp.org/identity/claims/adObjectGuidString"]
=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

@RuleName = "Identity Claims – ImmutableID To Name ID"
c:[Type == "
http://schemas.xmlsoap.org/claims/UPN"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

I swear everything was working, until some day I started to get the following errors:

….when navigating to: https://outlook.office365.com/owa/

image

Figure 1: Error When Using Federated Logon And Navigating To Office 365 Portal

….when navigating to: https://manage.windowsazure.com/default.aspx

image

Figure 2: Error When Using Federated Logon And Navigating To Azure AD Management Portal

….when navigating to: https://portal.office.com/

image

Figure 3: Error When Using Federated Logon And Navigating To Office 365 Management Portal

By giving the correlation ID to someone at Microsoft that is able to check it in the system logs, they most likely will be able to tell you what would be wrong. In this case unfortunately I as not able to do that. The logs on my system did not given me any clue!

As I have another ADFS v3.0 system in my environment, I therefore decided to configure that ADFS instance with all default values for DirSync and federation. After configuring all this, I was able to access Azure AD and Office 365 through federated logon on my ADFS v3.0 box, but still not on my ADFS v2.0.

After comparing the federation trusts between  ADFS v2.0 and Azure AD, and between ADFS v3.0 and Azure AD I saw the following difference:

image

Figure 4: Signature Hash Algorithm On The RP Trust On ADFS v3.0 For Azure AD/Office 365 (Default Config) – WORKING

image

Figure 5: Signature Hash Algorithm On The RP Trust On ADFS v2.0 For Azure AD/Office 365 (Custom Config) – NOT WORKING

For whatever reason, in the past I had changed the signature hash algorithm on the RP Trust On ADFS v2.0 For Azure AD/Office 365 AND I had forgotten about it. It took me some time to find this one, but by just changing the signature hash algorithm on the RP Trust On ADFS v2.0 For Azure AD/Office 365 from SHA-256 to SHA-1, everything started to work again! Yiiihhaaaaaa!

PS: this has NOTHING to do between the usage of ADFS v2.0 and ADFS v3.0. This was a configuration mistaken I made when playing around in the test/demo environment

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Azure AD Sync, DirSync, DirSync, Federation Trusts, Office 365, SSO, Transform Rules, Windows Azure Active Directory | 1 Comment »

(2014-03-12) Additional PowerShell Scripts For Migrating ADFS v2.x To ADFS v3.0

Posted by Jorge on 2014-03-12


In this article Microsoft explains how to migrate from ADFS v2.x to ADFS v3.0. In this blog post I have added multiple PowerShell scripts to help you migrate as automated as possible.

!!! DISCLAIMER/REMARKS !!!

  • These scripts are freeware, you are free to distribute it, but always refer to this website (https://jorgequestforknowledge.wordpress.com/) as the location where you got it
  • These scripts are furnished "AS IS". No warranty is expressed or implied!
  • Always test first in lab environment to see if it meets your needs!
  • Use these scripts at your own risk!
  • I do not warrant these scripts to be fit for any purpose, use or environment
  • I have tried to check everything that needed to be checked, but I do not guarantee these scripts do not have bugs.
  • I do not guarantee these scripts will not damage or destroy your system(s), environment or whatever.
  • I do not accept any liability in any way if you screw up, use the scripts wrong or in any other way where damage is caused to your environment/systems!
  • If you do not accept these terms do not use the scripts and delete it immediately!

!!! DISCLAIMER/REMARKS !!!

All scripts can also be downloaded from here.

+++++++++++++++++++++++++++++++++
++++++++++++++ PREPARE ++++++++++
+++++++++++++++++++++++++++++++++

# +++[P1]+++ Create Migration Folders #SCRIPT NAME --> "C:\TEMP\Create-Folders.ps1" New-Item "C:\ADFS-MIG" -ItemType Directory New-Item "C:\ADFS-MIG\Config" -ItemType Directory New-Item "C:\ADFS-MIG\Export" -ItemType Directory New-Item "C:\ADFS-MIG\Service" -ItemType Directory New-Item "C:\ADFS-MIG\Web" -ItemType Directory

++++++++++++++++++++++++++++++++

++++++++++++ EXPORT ++++++++++++

++++++++++++++++++++++++++++++++

# +++[E1]+++ Output Federation Service Properties (On ADFS STS Only!) #SCRIPT NAME --> "C:\ADFS-MIG\Output-Federation-Service-Properties.ps1" If (Test-Path -Path "C:\Program Files\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config") { Add-PSSnapIn Microsoft.ADFS.PowerShell } If (Test-Path -Path "C:\Windows\ADFS\Microsoft.IdentityServer.Servicehost.exe.config") { Import-Module ADFS } # Record ADFS Service Properties Get-Service -Name ADFSSRV | Select * | Out-File C:\ADFS-MIG\Config\ADFSService.txt Get-WmiObject win32_service | ?{$_.name -eq "ADFSSRV"} | Select * | Out-File C:\ADFS-MIG\Config\ADFSService.txt -Append # Record All ADFS Properties Get-ADFSProperties | Out-File C:\ADFS-MIG\Config\ADFSProperties.txt # Record All ADFS Endpoints Get-ADFSEndpoint | Out-File C:\ADFS-MIG\Config\ADFSEndpoint.txt # Record All ADFS Claim Descriptions Get-ADFSClaimDescription | Out-File C:\ADFS-MIG\Config\ADFSClaimDescription.txt # Record All ADFS Certificates Get-ADFSCertificate | Out-File C:\ADFS-MIG\Config\ADFSCertificate.txt # Record All ADFS Claims Provider Trusts Get-ADFSClaimsProviderTrust | Out-File C:\ADFS-MIG\Config\ADFSClaimsProviderTrust.txt # Record All ADFS Relying Party Trusts Get-ADFSRelyingPartyTrust | Out-File C:\ADFS-MIG\Config\ADFSRelyingPartyTrust.txt # Record All ADFS Attribute Stores Get-ADFSAttributeStore | %{ "##########" | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append "Store Name. = " + $_.Name | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append "Store Class = " + $_.StoreTypeQualifiedName | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append "Store Config:" | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append $_.Configuration.GetEnumerator() | %{ " * " + $_.Name + " = " + $_.Value | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append } "" | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append }

# +++[E2]+++ Export ANY CA Issued Certificate In Use By ADFS (On ADFS STS Only!) #SCRIPT NAME --> "C:\ADFS-MIG\Export-CA-Issued-Certificates-To-CER-And-PFX-From-ADFS-STS.ps1" $privateKeyProtectionPWD1 = Read-Host "Please Specify The Password To Protect The Private Keys..." $privateKeyProtectionPWD2 = Read-Host "Please Re-Type The Password To Protect The Private Keys..." If ($privateKeyProtectionPWD1 -ne $privateKeyProtectionPWD2) { Write-Host "Passwords DO NOT Match..." Write-Host "Aborting..." BREAK } Else { $certype = [System.Security.Cryptography.X509Certificates.X509ContentType]::pfx $ADFSCertificates = Get-ADFSCertificate $adfsSvcCommCert = $ADFSCertificates | ?{$_.CertificateType -eq "Service-Communications" -And $_.StoreLocation -eq "LocalMachine"} If (($adfsSvcCommCert | Measure-Object).Count -eq 1) { $adfsSvcCommCertThumbprint = $adfsSvcCommCert.Certificate.Thumbprint $adfsSvcCommCertName = "ADFS Service Communication Cert (STS)" $adfsSvcCommCertInLocalStore = Get-ChildItem -path cert:\LocalMachine\My | ?{$_.Thumbprint -eq $adfsSvcCommCertThumbprint} If ($adfsSvcCommCertInLocalStore.HasPrivateKey -eq $true -And $adfsSvcCommCertInLocalStore.PrivateKey.CspKeyContainerInfo.Exportable -eq $true) { $adfsSvcCommCertBytesCER = $adfsSvcCommCertInLocalStore.export("Cert") [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsSvcCommCertName + ".cer"), $adfsSvcCommCertBytesCER) $adfsSvcCommCertBytesPFX = $adfsSvcCommCertInLocalStore.export($certype, $privateKeyProtectionPWD1) [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsSvcCommCertName + ".pfx"), $adfsSvcCommCertBytesPFX) } } $adfsTokenSignCert = $ADFSCertificates | ?{$_.CertificateType -eq "Token-Signing" -And $_.StoreLocation -eq "LocalMachine"} If (($adfsTokenSignCert | Measure-Object).Count -ge 1) { $i = 1 $adfsTokenSignCert | %{ $adfsTokenSignCertThumbprint = $_.Certificate.Thumbprint $adfsTokenSignCertName = "ADFS Token Signing Cert (STS) (" + $i + ")" $adfsTokenSignCertInLocalStore = Get-ChildItem -path cert:\LocalMachine\My | ?{$_.Thumbprint -eq $adfsTokenSignCertThumbprint} If ($adfsTokenSignCertInLocalStore.HasPrivateKey -eq $true -And $adfsTokenSignCertInLocalStore.PrivateKey.CspKeyContainerInfo.Exportable -eq $true) { $adfsTokenSignCertBytesCER = $adfsTokenSignCertInLocalStore.export("Cert") [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsTokenSignCertName + ".cer"), $adfsTokenSignCertBytesCER) $adfsTokenSignCertBytesPFX = $adfsTokenSignCertInLocalStore.export($certype, $privateKeyProtectionPWD1) [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsTokenSignCertName + ".pfx"), $adfsTokenSignCertBytesPFX) } $i += 1 } } $adfsTokenEncryptCert = $ADFSCertificates | ?{$_.CertificateType -eq "Token-Decrypting" -And $_.StoreLocation -eq "LocalMachine"} If (($adfsTokenEncryptCert | Measure-Object).Count -ge 1) { $j = 1 $adfsTokenEncryptCert | %{ $adfsTokenEncryptCertThumbprint = $_.Certificate.Thumbprint $adfsTokenEncryptCertName = "ADFS Token Encryption Cert (STS) (" + $j + ")" $adfsTokenEncryptCertInLocalStore = Get-ChildItem -path cert:\LocalMachine\My | ?{$_.Thumbprint -eq $adfsTokenEncryptCertThumbprint} If ($adfsTokenEncryptCertInLocalStore.HasPrivateKey -eq $true -And $adfsTokenEncryptCertInLocalStore.PrivateKey.CspKeyContainerInfo.Exportable -eq $true) { $adfsTokenEncryptCertBytesCER = $adfsTokenEncryptCertInLocalStore.export("Cert") [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsTokenEncryptCertName + ".cer"), $adfsTokenEncryptCertBytesCER) $adfsTokenEncryptCertBytesPFX = $adfsTokenEncryptCertInLocalStore.export($certype, $privateKeyProtectionPWD1) [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsTokenEncryptCertName + ".pfx"), $adfsTokenEncryptCertBytesPFX) } $j += 1 } } }

# +++[E3]+++ Export The ADFS v2.x Configuration To XML Files (On ADFS STS Only!) #Get PoSH Script From W2K12R2 Media (Folder: <CD>\Support\Adfs) Or Folder C:\Windows\Adfs After Installation ADFS Role #Copy Script To Folder "C:\ADFS-MIG" On Source ADFS Server C:\ADFS-MIG\Export-FederationConfiguration.ps1 -Path C:\ADFS-MIG\Export

# +++[E4]+++ Copy The ADFS v2.x Web Configuration Files (On ADFS STS And ADFS Proxy!) #SCRIPT NAME --> "C:\ADFS-MIG\Copy-ADFS-Web-Server-Configuration-Files.ps1" Import-Module WebAdministration $adfsWebPath = (Get-WebApplication "adfs/ls").PhysicalPath Copy-Item $($adfsWebPath + "\*") "C:\ADFS-MIG\Web" -Recurse

# +++[E5]+++ Copy The ADFS v2.x Service Configuration Files (On ADFS STS And ADFS Proxy!) #SCRIPT NAME --> "C:\ADFS-MIG\Copy-ADFS-Web-Service-Configuration-File.ps1" If (Test-Path -Path "C:\Program Files\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config") { Copy-Item "C:\Program Files\Active Directory Federation Services 2.0\*") "C:\ADFS-MIG\Service" -Recurse } If (Test-Path -Path "C:\Windows\ADFS\Microsoft.IdentityServer.Servicehost.exe.config") { Copy-Item "C:\Windows\ADFS\*") "C:\ADFS-MIG\Service" -Recurse }

# +++[E6]+++ Export ANY CA Issued Certificate In Use By ADFS (On ADFS Proxy Only!) #SCRIPT NAME --> "C:\ADFS-MIG\Export-CA-Issued-Certificates-To-CER-And-PFX-From-ADFS-PRX.ps1" $privateKeyProtectionPWD1 = Read-Host "Please Specify The Password To Protect The Private Keys..." $privateKeyProtectionPWD2 = Read-Host "Please Re-Type The Password To Protect The Private Keys..." If ($privateKeyProtectionPWD1 -ne $privateKeyProtectionPWD2) { Write-Host "Passwords DO NOT Match..." Write-Host "Aborting..." BREAK } Else { $certype = [System.Security.Cryptography.X509Certificates.X509ContentType]::pfx $adfsSvcCommCertThumbprint = (Get-WebBinding "Default Web Site" -protocol https).certificateHash $adfsSvcCommCertName = "ADFS Service Communication Cert (PRX)" $adfsSvcCommCertInLocalStore = Get-ChildItem -path cert:\LocalMachine\My | ?{$_.Thumbprint -eq $adfsSvcCommCertThumbprint} If ($adfsSvcCommCertInLocalStore.HasPrivateKey -eq $true -And $adfsSvcCommCertInLocalStore.PrivateKey.CspKeyContainerInfo.Exportable -eq $true) { $adfsSvcCommCertBytesCER = $adfsSvcCommCertInLocalStore.export("Cert") [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsSvcCommCertName + ".cer"), $adfsSvcCommCertBytesCER) $adfsSvcCommCertBytesPFX = $adfsSvcCommCertInLocalStore.export($certype, $privateKeyProtectionPWD1) [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsSvcCommCertName + ".pfx"), $adfsSvcCommCertBytesPFX) } }

+++++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++ CREATE/JOIN/CONFIGURE ADFS ++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++

# +++[C1]+++ Create ADFS Farm Using WID And ADFS Managed Self-Signed Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Create-ADFS-Farm-WID-Self-Signed-Certs.ps1" $adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..." $adfsSvcName = Read-Host "Please Specify The Display Name Of The Federation Service..." $adfsSvcCreds = Get-Credential Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Install-AdfsFarm -OverwriteConfiguration:$true -FederationServiceName $adfsSvcFQDN -FederationServiceDisplayName $adfsSvcName -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C2]+++ Create ADFS Farm Using WID And CA Issued Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Create-ADFS-Farm-WID-CA-Issued-Certs.ps1" $adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..." $adfsSvcName = Read-Host "Please Specify The Display Name Of The Federation Service..." $adfsSvcCreds = Get-Credential Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Install-AdfsFarm -OverwriteConfiguration:$true -FederationServiceName $adfsSvcFQDN -FederationServiceDisplayName $adfsSvcName -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint -SigningCertificateThumbprint $adfsTokenSignCertThumbprint -DecryptionCertificateThumbprint $adfsTokenEncryptCertThumbprint | FL

# +++[C3]+++ Create ADFS Farm Using SQL And ADFS Managed Self-Signed Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Create-ADFS-Farm-SQL-Self-Signed-Certs.ps1" $adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..." $adfsSvcName = Read-Host "Please Specify The Display Name Of The Federation Service..." $adfsSvcCreds = Get-Credential $sqlServerInstance = Read-Host "Please Specify The FQDN Of The SQL Server And SQL Instance..." $sqlConnectionString = "Data Source=$sqlServerInstance;Initial Catalog=AdfsConfiguration;Integrated Security=True" Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Install-AdfsFarm -OverwriteConfiguration:$true -FederationServiceName $adfsSvcFQDN -FederationServiceDisplayName $adfsSvcName -ServiceAccountCredential $adfsSvcCreds -SQLConnectionString $sqlConnectionString -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C4]+++ Create ADFS Farm Using SQL And CA Issued Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Create-ADFS-Farm-SQL-CA-Issued-Certs.ps1" $adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..." $adfsSvcName = Read-Host "Please Specify The Display Name Of The Federation Service..." $adfsSvcCreds = Get-Credential $sqlServerInstance = Read-Host "Please Specify The FQDN Of The SQL Server And SQL Instance..." $sqlConnectionString = "Data Source=$sqlServerInstance;Initial Catalog=AdfsConfiguration;Integrated Security=True" Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" $adfsTokenSignCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Token Signing Certificate" $adfsTokenEncryptCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Token Encryption Certificate" Add-WindowsFeature ADFS-Federation Install-AdfsFarm -OverwriteConfiguration:$true -FederationServiceName $adfsSvcFQDN -FederationServiceDisplayName $adfsSvcName -ServiceAccountCredential $adfsSvcCreds -SQLConnectionString $sqlConnectionString -CertificateThumbprint $adfsSvcCommCertThumbprint -SigningCertificateThumbprint $adfsTokenSignCertThumbprint -DecryptionCertificateThumbprint $adfsTokenEncryptCertThumbprint | FL

# +++[C5]+++ Join ADFS Farm Using WID And ADFS Managed Self-Signed Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Join-ADFS-Farm-WID-Self-Signed-Certs.ps1" $adfsSvcCreds = Get-Credential $adfsPrimaryServer = Read-Host "Please Specify The FQDN Of The Primary Server..." Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Add-AdfsFarmNode -PrimaryComputerName $adfsPrimaryServer -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C6]+++ Join ADFS Farm Using WID And CA Issued Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Join-ADFS-Farm-WID-CA-Issued-Certs.ps1" $adfsSvcCreds = Get-Credential $adfsPrimaryServer = Read-Host "Please Specify The FQDN Of The Primary Server..." Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Add-AdfsFarmNode -PrimaryComputerName $adfsPrimaryServer -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C7]+++ Join ADFS Farm Using SQL And ADFS Managed Self-Signed Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Join-ADFS-Farm-SQL-Self-Signed-Certs.ps1" $adfsSvcCreds = Get-Credential $sqlServerInstance = Read-Host "Please Specify The FQDN Of The SQL Server And SQL Instance..." $sqlConnectionString = "Data Source=$sqlServerInstance;Initial Catalog=AdfsConfiguration;Integrated Security=True" Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Add-AdfsFarmNode -SQLConnectionString $sqlConnectionString -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C8]+++ Join ADFS Farm Using SQL And CA Issued Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Join-ADFS-Farm-SQL-CA-Issued-Certs.ps1" $adfsSvcCreds = Get-Credential $sqlServerInstance = Read-Host "Please Specify The FQDN Of The SQL Server And SQL Instance..." $sqlConnectionString = "Data Source=$sqlServerInstance;Initial Catalog=AdfsConfiguration;Integrated Security=True" Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Add-AdfsFarmNode -SQLConnectionString $sqlConnectionString -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C9]+++ Install And Configure Web Application Proxy #SCRIPT NAME --> "C:\ADFS-MIG\Install-And-Configure-Web-Application-Proxy.ps1" Add-WindowsFeature Web-Application-Proxy -IncludeManagementTools $adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..." $adfsAdminCreds = Get-Credential Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Install-WebApplicationProxy -FederationServiceName $adfsSvcFQDN -FederationServiceTrustCredential $adfsAdminCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C10]+++ Add/Publish Web Applications Through Web Application Proxy Get-WebApplicationProxyApplication --> http://technet.microsoft.com/en-us/library/dn283413.aspx Get-WebApplicationProxyAvailableADFSRelyingParty --> http://technet.microsoft.com/en-us/library/dn283412.aspx Add-WebApplicationProxyApplication --> http://technet.microsoft.com/en-us/library/dn283409.aspx

++++++++++++++++++++++++++++++++

++++++++++++ IMPORT ++++++++++++

++++++++++++++++++++++++++++++++

# +++[I1]+++ Import ANY CA Issued Certificate In Use By ADFS (On ADFS STS Only!) (Only Works On W2K12R2!!!) #SCRIPT NAME --> "C:\ADFS-MIG\Import-CA-Issued-Certificates-Into-ADFS-STS-Local-Cert-Store.ps1" $privateKeyProtectionPWD = ConvertTo-SecureString -String $(Read-Host "Please Specify The Password Protecting The Private Keys...") -Force –AsPlainText $adfsSvcCommCertPFXFile = Get-ChildItem -Path 'C:\ADFS-MIG\Config' -Filter 'ADFS Service Communication Cert (STS).pfx' If (($adfsSvcCommCertPFXFile | Measure-Object).Count -ge 1) { Import-PfxCertificate -FilePath $($adfsSvcCommCertPFXFile.FullName) -CertStoreLocation 'cert:\localMachine\my' –Exportable -Password $privateKeyProtectionPWD } $adfsTokenSignCertPFXFile = Get-ChildItem -Path 'C:\ADFS-MIG\Config' -Filter 'ADFS Token Signing Cert (STS)*.pfx' If (($adfsTokenSignCertPFXFile | Measure-Object).Count -ge 1) { $adfsTokenSignCertPFXFile | %{Import-PfxCertificate -FilePath $($_.FullName) -CertStoreLocation 'cert:\localMachine\my' –Exportable -Password $privateKeyProtectionPWD} } $adfsTokenEncryptCertPFXFile = Get-ChildItem -Path 'C:\ADFS-MIG\Config' -Filter 'ADFS Token Encryption Cert (STS)*.pfx' If (($adfsTokenEncryptCertPFXFile | Measure-Object).Count -ge 1) { $adfsTokenEncryptCertPFXFile | %{Import-PfxCertificate $($_.FullName) -CertStoreLocation 'cert:\localMachine\my' –Exportable -Password $privateKeyProtectionPWD} }

# +++[I2]+++ Import The ADFS v2.x Configuration From The XML Files Into ADFS v3.0 #Get PoSH Script From W2K12R2 Media (Folder: <CD>\Support\Adfs) Or Folder C:\Windows\Adfs After Installation ADFS Role #Copy Script To Folder "C:\ADFS-MIG" On Source ADFS Server C:\ADFS-MIG\Import-FederationConfiguration.ps1 -Path C:\ADFS-MIG\Export

# +++[I3]+++ Import ANY CA Issued Certificate In Use By ADFS (On ADFS Proxy/WAP Only!) (Only Works On W2K12R2!!!) #SCRIPT NAME --> "C:\ADFS-MIG\Import-CA-Issued-Certificates-Into-ADFS-PRX-Local-Cert-Store.ps1" $privateKeyProtectionPWD = ConvertTo-SecureString -String $(Read-Host "Please Specify The Password Protecting The Private Keys...") -Force –AsPlainText $adfsSvcCommCertPFXFile = Get-ChildItem -Path 'C:\ADFS-MIG\Config' -Filter 'ADFS Service Communication Cert (PRX).pfx' If (($adfsSvcCommCertPFXFile | Measure-Object).Count -ge 1) { Import-PfxCertificate -FilePath $($adfsSvcCommCertPFXFile.FullName) -CertStoreLocation 'cert:\localMachine\my' –Exportable -Password $privateKeyProtectionPWD }

A while back I also found a blog post with PowerShell script to quickly deploy both ADFS v3.0 and WAP. You can find that blog post here.

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER:

https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

#########

http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Certificates, Farm, Federation Trusts, Migration, Proxy Service, Security Token Service (STS) | 4 Comments »

(2014-02-10) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v3.0 (Update 1)

Posted by Jorge on 2014-02-10


In this blog post I wrote and concluded about the bare minimum acceptance transform rules for the default claims provider trust (Active Directory) in ADFS v3.0 (or ADFS 2012 R2). What I wrote is still correct, however, unfortunately the final conclusion is inaccurate. I do not understand what went wrong when I tested that. While both ADFS v2.0 and ADFS v2.1, at a minimum require the "Primary SID" claim, ADFS v3.0 does not only require the "Windows Account Name" claim as I stated in the previous post. It requires an additional claim, being the "UPN" claim, at a minimum. Continue reading to understand and see what goes wrong if any of the two required claims is missing.

To enable debug tracing, before trying this yourself see: (2014-02-05) Enabling Debug Tracing In ADFS v2.1 and v3.0

If you only have the following claims rule in the acceptance transform rules list of the Active Directory CP trust…

image

Figure 1: Only Using The Claims Rules For The "Windows Account Name" Claim

…and you access, for example, https://<FQDN Federation Service>/adfs/ls/IdPInitiatedSignOn, you will an error similar to the one below

image

Figure 2: The ADFS Error Page

Looking at the ADFS Admin Event Log you will something similar to the figure below.. Pay specific attention to the text "ID4250: The ClaimValue cannot be null". That means, the "UPN" claim is missing or does not have a value.

image

Figure 3: The Error "System.IO.InvalidDataException: ID4250: The ClaimValue Cannot Be Null" In The ADFS Admin Event Log

Looking at the ADFS Debug Tracing Event Log you will something similar to the figure below. Now it really tells you what’s wrong! Just like I said earlier.

image

Figure 4: The Error "Unable To Find Upn Claim In The Incoming Identity Or Claim Value Is Empty" In The ADFS Debug Tracing Event Log

Looking at the ADFS Debug Tracing Event Log you will something similar to the figure below, which is almost the same error as mentioned earlier.

image

Figure 5: The Error "Exception: ID4250: The ClaimValue Cannot Be Null" In The ADFS Debug Tracing Event Log

You will also see the following error, which is not really helpful.

image

Figure 6: The Error "Passive Pipeline Error" In The ADFS Debug Tracing Event Log

Now, if you only have the following claims rule in the acceptance transform rules list of the Active Directory CP trust…

image

Figure 7: Only Using The Claims Rules For The "UPN" Claim

…and you access, for example, https://<FQDN Federation Service>/adfs/ls/IdPInitiatedSignOn, you will an error similar to the one below

image

Figure 8: The ADFS Error Page

Looking at the ADFS Admin Event Log you will something similar to the figure below.. Pay specific attention to the text "SessionSecurityToken does not contain a single AnchorID claim". That means, the "Windows Account Name" claim is missing or does not have a value.

image

Figure 9: The Error "SessionSecurityToken Does Not Contain A Single AnchorID Claim" In The ADFS Admin Event Log

Looking at the ADFS Debug Tracing Event Log you will something similar to the figure below. It is telling you the same as before without really telling you what is actually wrong.

image

Figure 10: The Error "SessionSecurityToken Does Not Contain A Single AnchorID Claim" In The ADFS Debug Tracing Event Log

You will also see the following error, which is not really helpful.

image

Figure 11: The Error "Token Is Invalid" In The ADFS Debug Tracing Event Log

You will also see the following error, which is not really helpful.

image

Figure 12: The Error "Exception: MSIS7012: An Error Occurred While Processing The Request" In The ADFS Debug Tracing Event Log

You will also see the following error, which is not really helpful.

image

Figure 13: The Error "Passive Pipeline Error" In The ADFS Debug Tracing Event Log

Now, if you have both the following claims rule in the acceptance transform rules list of the Active Directory CP trust…

image

Figure 14: Only Using The Claims Rules For The The "Windows Account Name" Claim And The "UPN" Claim

…and you access, for example, https://<FQDN Federation Service>/adfs/ls/IdPInitiatedSignOn, you will an error similar to the one below

image

Figure 15: The ADFS SignIn Page

Voila it works! Smile

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Claims Rule Language, Federation Trusts, Transform Rules | 4 Comments »

(2013-10-09) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v3.0

Posted by Jorge on 2013-10-09


UPDATE: See a newer and more up-to-date and accurate version of this blog post here.

This post is about the bare minimum acceptance transform rules for the default claims provider trust (Active Directory) in ADFS v3.0. To read about the same topic in ADFS v2.0 see the following blog post: (2011-09-13) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v2.0

Right after installing ADFS v3.0, by default it will have ONE Claims Provider Trust configuration for AD as the one and only supported authentication store. ADFS v3.0, like ADFS v2.0, does not support any other authentication store besides AD. That Claims Provider Trust will also be configure with a default set of Acceptance Transform Rules as shown below in the picture.

image

Figure 1: Default List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0

It is of course possible to adjust the default set of Acceptance Transform Rules by removing existing default rules and/or adding your own required rules. Assuming you would do such a thing, you could for example replace the default set of Acceptance Transform Rules, with the Acceptance Transform Rules as shown below. If you look carefully I removed the default Acceptance Transform Rules and put in my own Acceptance Transform Rules.

image

Figure 2: Custom List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0

If I now try to access a Claims Based SharePoint site that I created and configured on SharePoint 2010, you would see something similar to what you would see below.

The default Home Realm Discovery window with the selection list. The logo you see is something that I configured. I  get to this screen because I have multiple Claims Provider Trusts configured, one for the default authentication store being AD and one for an IdP-STS at some other organization.

image

Figure 3: The Default Home Realm Discovery Page In ADFS v3.0 Using A Selection List Of The Configured Claims Provider Trusts (a.k.a. Identity Providers)

After selecting the one you see, which represents in this case the Claims Provider Trust for AD, and clicking “Continue To Sign In”, you will see something similar to the sign-in page for which I already filled in some credentials:

image

Figure 4: The Default Sign-In Web Page For Forms AuthN In ADFS v3.0 To Collect Credentials For Authentication

After clicking “Sign In”, you will see something similar to:

image

Figure 5: Some Error Stating Something Went Wrong

After errors like this, the next step is to check the ADFS Event Logs. Let’s try the Admin log first! Note the detailed information!

You should see something similar like:

Event ID 364…

image

Figure 6: Event ID 364 In the ADFS v3.0 Admin Event Log Stating The Session Security Token Does Not Contain A Single AnchorID Claim

Encountered error during federation passive request.

Additional Data

Protocol Name:
wsfed

Relying Party:
urn:app:sharepointclaimsappwap

Exception details:
Microsoft.IdentityServer.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. —> Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnIdentityInvalidException: SessionSecurityToken does not contain a single AnchorID claim.
   at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.ValidateToken(SessionSecurityToken token, SessionSecurityToken currentToken)
   at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.AddToken(SessionSecurityToken newToken)
   at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateSingleSignOnTokenInContext(ProtocolContext context, SecurityToken ssoToken)
   — End of inner exception stack trace —
   at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateSingleSignOnTokenInContext(ProtocolContext context, SecurityToken ssoToken)
   at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSsoSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken, SecurityToken& ssoSecurityToken)
   at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
   at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
   at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.Process(ProtocolContext context)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnIdentityInvalidException: SessionSecurityToken does not contain a single AnchorID claim.
   at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.ValidateToken(SessionSecurityToken token, SessionSecurityToken currentToken)
   at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.AddToken(SessionSecurityToken newToken)
   at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateSingleSignOnTokenInContext(ProtocolContext context, SecurityToken ssoToken)

"Does not contain a single AnchorID claim"????? Oh yeah, wait! In ADFS v2.0 you were required to have the objectSID (a.k.a. the PrimarySID) as the minimum claim. So let’s add that!

image

Figure 7: Custom List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0, But NOW With The Primary SID Claim

So, let’s try again!

No good, as I got the same error as shown in figure 5 and 6. Hey something changed here!

In a previous blog post "(2013-10-07) Restoring The Default Acceptance Transform Rules For The AD CP Trust In ADFS v3.0" I explain how to restore the default list of Acceptance Transform Rules for the default Claims Provider Trust (AD) in ADFS v3.0 if it is broken and you cannot get it to work anymore. It is really easy to “restore” the default list of Acceptance Transform Rules.

However, after some testing I found out that ADFS v3.0 requires AT LEAST one identifier claim that allows an authenticated user to request a security token. In ADFS v2.0, the identifier (a.k.a. the AnchorID Claim) was the "Primary SID" claim, but in ADFS v3.0 that was changed to the "Windows Account Name" claim!!!

image

Figure 8: The Bare Minimum Acceptance Transform Rules List Required For ADFS v3.0 To Issue A Security Token

AND…. there must be only one "Windows Account Name" claim. There should NOT be multiple values for that claim, either passing through or extracted by an LDAP query as shown below.

image

Figure 9: Custom List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0, But NOW With MULTIPLE "Windows Account Name" Claims

If you have multiple "Windows Account Name" claims, which resulted from claims rules as shown in figure 9, it will not work and throw similar errors as shown in figure 5 and 6. Read it carefully, It clearly states: "SessionSecurityToken does not contain a single AnchorID claim". SINGLE, not multiple claims for the AnchorID claim, which is the "Windows Account Name" claim!

So in my scenario having the following claims rules worked like a charm!

image

Figure 10: Combination Of Acceptance Transform Rules From Figure 2 And Figure 8

Now trying to access my claims based SharePoint web site again will result in the following:

image

Figure 11: Successful Access To A Claims Based SharePoint Web Site Hosted SharePoint 2010 That Includes A Custom Web Part To Show The Claims Processed By SharePoint 2010

So……to summarize

For even ADFS v3.0 to be able to issue a security token, the Acceptance Transform Rule List Must AT LEAST have the claim rule specified as shown in figure 8! The value for the "Windows Account Name" claim must be in the format <NetBIOS Domain Name>\<sAMAccountName> (e.g. ADCORP\ADM.ROOT) as shown in figure 11. When you upgrade, or better migrate from ADFS v2.0 to ADFS v3.0 you need to be aware of this change!

UPDATE: See a newer and more up-to-date and accurate version of this blog post here.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Claims Rule Language, Federation Trusts, Transform Rules | 1 Comment »

(2013-10-07) Restoring The Default Acceptance Transform Rules For The AD CP Trust In ADFS v3.0

Posted by Jorge on 2013-10-07


In the following post, you can see how to restore the default acceptance transform rules for Active Directory claims provider trust in either ADFS v2.0 (on W2K8 or W2K8R2) or ADFS v2.1 (on W2K12): AD FS 2.0: How to Restore the Default Acceptance Transform Rules for the Active Directory Claims Provider Trust. The only difference between W2K8(R2) and W2K12 is that in W2K8(R2) you need to load a PowerShell snap-in (Add-PSSnapin Microsoft.Adfs.PowerShell) and in W2K12 (and higher) you need to load a PowerShell module (Import-Module ADFS)

In this post you can see how to restore the default acceptance transform rules for Active Directory claims provider trust in ADFS v3.0 (on W2K12R2). Has the procedure changed? No not really. Instead of a snap-in you now need to load a module and the default acceptance transform rules have changed a bit. For completeness I have described the procedure in full in this blog post.

So if you have modified the default acceptance transform rules for the Active Directory claims provider trust in ADFS v3.0, and you want to restore the defaults you can use this procedure. You need to perform this procedure on an ADFS STS server with write access to the ADFS configuration database. When using SQL you can use any ADFS STS server, but when using WID you must use the primary ADFS STS server.

[1] Copy the following text into a file and save that file as C:\TEMP\CP_ActiveDirectory_AcceptanceTransformRules_Default.txt

@RuleTemplate = "PassThroughClaims" @RuleName = "Pass through all Windows account name claims" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "Pass through all Name claims" c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "Pass through all Primary SID claims" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "Pass through all Group SID claims" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "Pass through all Primary group SID claims" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "Pass through all Deny only group SID claims" c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/denyonlysid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "Pass through all Deny only primary SID claims" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlyprimarysid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "Pass through all Deny only primary group SID claims" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlyprimarygroupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "Pass through all Enhanced Key Usage claims" c:[Type == "http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "Pass through all UPN claims" c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c);

[2] Open a PowerShell Command Prompt window

[3] Execute the following commands:

[a] Import-Module ADFS

[b] Set-AdfsClaimsProviderTrust -TargetName "Active Directory" -AcceptanceTransformRulesFile "C:\TEMP\CP_ActiveDirectory_AcceptanceTransformRules_Default.txt"

[4] To verify your changes:

[a] Open the AD FS Management MMC

[b] Navigate to the node called "Trust Relationships" and select the sub-node "Claims Provider Trusts"

[c] Right-click the "Active Directory" CP trust and select "Edit Claim Rules"

You should now see something similar to:

image

Figure 1: Default List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Claims Rule Language, Federation Trusts, Transform Rules | 1 Comment »

 
%d bloggers like this: