Archive for the ‘Certificates’ Category

(2020-07-08) Federation Metadata From ADFS Adjusted To Support “Broken” Applications

Posted by Jorge on 2020-07-08

In ADFS when the primary Token Signing certificate and the primary Token Encryption certificate are going to expire you MUST start the certificate change process to change the certificates in ADFS, but also in every connected system or application.

When updating the Token Signing certificate and the Token Encryption certificate the following is important to remember:

From a connected system/application perspective:

Downstream federation systems care about your Token Signing certificate and Token Encryption certificate
Upstream federation systems and application only care about your Token Signing certificate

From a certificate perspective:

Token Signing certificate is important for both downstream federation systems and upstream federation systems and applications
Token Encryption certificate is important for both downstream federation systems only

–

How you get the certificates to these systems and applications depends on your process, but in general:

The federation metadata URL from ADFS is consumed
The federation metadata from an XML file is consumed, after exporting it from the URL
The certificates, in some format, are consumed by the application

–

Let’s focus on the first and second option.

–

By default:

ADFS publishes the federation metadata through the following URL: /federationmetadata/2007-06/federationmetadata.xml">/federationmetadata/2007-06/federationmetadata.xml">https://<Federation Service FQDN>/federationmetadata/2007-06/federationmetadata.xml
ADFS publishes ALL configured Token Signing certificates in the federation metadata, in the order from oldest to most recent (changing from primary to secondary or vice versa DOES NOT influence the order in the federation metadata!)
ADFS only publishes the configured primary Token Encryption certificate in the federation metadata
ADFS signs the federation metadata with the configured primary Token Signing certificate

–

In my TEST environment I have configured my ADFS server with 5 Token Signing certificates, so that it is as clear as possible.

–

The federation metadata contains 4 sections/nodes where all the Token certificates are specified:

The ‘RoleDescriptor’ Node For The Type Of ‘fed:ApplicationServiceType’ Containing Only The Primary Token Encryption Certificate (not displayed below, as it is not important for this scenario)
The ‘RoleDescriptor’ Node For The Type Of ‘fed:SecurityTokenServiceType’ Containing All Token Signing Certificates (displayed in figure 1)
The ‘SPSSODescriptor’ Node Containing All Token Signing Certificates And The Primary Token Encryption Certificate (displayed in figure 2)
The ‘IdPSSODescriptor’ Node Containing All Token Signing Certificates And The Primary Token Encryption Certificate (displayed in figure 3)

Figure 1: The ‘RoleDescriptor’ Node For The Type Of ‘fed:SecurityTokenServiceType’ Containing All Token Signing Certificates

–

Figure 2: The ‘SPSSODescriptor’ Node Containing All Token Signing Certificates (And The Primary Token Encryption Certificate)

–

Figure 3: The ‘IdPSSODescriptor’ Node Containing All Token Signing Certificates (And The Primary Token Encryption Certificate)

–

Now the following scenarios are possible when consuming the federation metadata:

All Token Signing certificates are read and all are consumed by the application – The import of the federation metadata in the application can be done at ANY time!
All Token Signing certificates are read and and only the LAST occurrence is consumed by the application – The import of the federation metadata in the application must only be done right after the switch of the Token Signing certificates (i.e. the newest secondary Token Signing certificate becomes the new primary Token Signing certificate)
All Token Signing certificates are read and and only the FIRST occurrence is consumed by the application – The import of the federation metadata in the application must only be done right after the switch of the Token Signing certificates (i.e. the newest secondary Token Signing certificate becomes the new primary Token Signing certificate) AND the imported federation metadata MUST be adjusted before the import!

–

Preferably the application behaves like [1]. That is the BEST option without any issues. If that is not possible, it at least behaves like option [2], which requires somewhat more control and planning. With option [3], my opinion is that the application is by default broken and does not adhere to best practices. The person that build it, did not get it how things work.

–

As with option [3] the application only consumes the first Token Signing Certificate and ignores all others, the only way to make it read the last occurrence of the Token Signing certificate as the first one, is by removing all other occurrences. Looking at any of the pictures above, that means you need to remove all the occurrences of the section “<KeyDescriptor use="signing">…</KeyDescriptor>” before the LAST (newest) Token Signing certificate. You can do this either manually or through PowerShell

Through PowerShell, you can use the following script and command line option to remove all the Token Signing certificate occurrences, except the last occurrence, from the XML federation metadata file:

Invoke-Command -ScriptBlock {
    # Get The Date And Time
    $execDateTime = Get-Date
    $execDateTimeCustom = Get-Date $execDateTime -Format "yyyy-MM-dd_HH.mm.ss"

    # Federation Service FQDN
    $federationServiceFQDN = "<Federation Service FQDN>" # e.g. "FS.COMPANY.COM"

    # Folder Path For The Federation Metadata XML File
    $fedMetadataXMLFolderPath = "<Folder Path For The Federation Metadata XML File>" # e.g. "C:\TEMP"

    # File Path For The Federation Metadata XML File(s)
    $fedMetadataXMLFilePath = Join-Path $fedMetadataXMLFolderPath $($federationServiceFQDN + "_FederationMetadata_" + $execDateTimeCustom + ".xml")
    $fedMetadataXMLLastTSOnlyFilePath = Join-Path $fedMetadataXMLFolderPath $($federationServiceFQDN + "_FederationMetadata_" + $execDateTimeCustom + "LastTSOnlyNoSignature.xml")

    # URL for the federation metadata: https://<Federation Service FQDN>/federationmetadata/2007-06/federationmetadata.xml
    $fedMetadataURL = "https://$federationServiceFQDN/federationmetadata/2007-06/federationmetadata.xml"

    # Download The Metadata To An XML File
    $webClient = New-Object System.Net.WebClient
    $webClient.DownloadFile($fedMetadataURL, $fedMetadataXMLFilePath)

    # Read The Downloaded XML Metadata File And Define Several Variables With Namespace Info
    $fedMetadataXMLMetadata = [xml](Get-Content $fedMetadataXMLFilePath)
    $xmlnamespace = $fedMetadataXMLMetadata.EntityDescriptor.xmlns
     $xmlds = $fedMetadataXMLMetadata.EntityDescriptor.Signature.ds
    $xmlxsi = $fedMetadataXMLMetadata.EntityDescriptor.RoleDescriptor[0].xsi
    $xmlfed = $fedMetadataXMLMetadata.EntityDescriptor.RoleDescriptor[0].fed
    $namespace = @{xmlnamespace = $xmlnamespace;xmlds = $xmlds;xmlxsi = $xmlxsi;xmlfed = $xmlfed}
    $ns = New-Object System.Xml.XmlNamespaceManager($fedMetadataXMLMetadata.NameTable)
    $ns.AddNamespace("xmlnamespace", $xmlnamespace)
    $ns.AddNamespace("xmlds", $xmlds)
    $ns.AddNamespace("xmlxsi", $xmlxsi)
    $ns.AddNamespace("xmlfed", $xmlfed)

    # Save The Original Federation Metadata File So That It Has Prettier Format
    $fedMetadataXMLMetadata.Save($fedMetadataXMLFilePath)

    # Get The Nodes For The Role Descriptor And Count The Number Of Occurences Of The Token Signing Certificate
    $roleDescriptorTSCerts = Select-Xml -Xml $fedMetadataXMLMetadata -XPath $("/xmlnamespace:EntityDescriptor/xmlnamespace:RoleDescriptor[@xmlxsi:type=’fed:SecurityTokenServiceType’]/xmlnamespace:KeyDescriptor[@use=’signing’]") -Namespace $namespace
    $roleDescriptorTSCertsCount = $roleDescriptorTSCerts.Count

    # Start And End Iteration Point
    $start = $roleDescriptorTSCertsCount – 2
    $end = 0

    # Get The Parent Node Of The Token Signing Certificate Nodes In The Role Descriptor And The Specified Token Signing Certificates
    $roleDescriptorTSCertsParent = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor/xmlnamespace:RoleDescriptor[@xmlxsi:type=’fed:SecurityTokenServiceType’]", $ns)
    $roleDescriptorTSCertsData = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor/xmlnamespace:RoleDescriptor[@xmlxsi:type=’fed:SecurityTokenServiceType’]/xmlnamespace:KeyDescriptor[@use=’signing’]", $ns)

    # Process And Delete All Ocurrences Of The Token Signing Certificate Except Last Token Signing Certificate
    For ($i = $start; $i -ge $end; $i–) {
        $roleDescriptorTSCertsParent.RemoveChild($roleDescriptorTSCertsData[$i]) | Out-Null
    }

    # Get The Parent Node Of The Token Signing Certificate Nodes In The IDP Descriptor And The Specified Token Signing Certificates
    $idpSSODescriptorTSCertsParent = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor/xmlnamespace:IDPSSODescriptor", $ns)
    $idpSSODescriptorTSCertsData = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor/xmlnamespace:IDPSSODescriptor/xmlnamespace:KeyDescriptor[@use=’signing’]", $ns)

    # Process And Delete All Ocurrences Of The Token Signing Certificate Except Last Token Signing Certificate
    For ($i = $start; $i -ge $end; $i–) {
        $idpSSODescriptorTSCertsParent.RemoveChild($idpSSODescriptorTSCertsData[$i]) | Out-Null
    }

    # Get The Parent Node Of The Token Signing Certificate Nodes In The SP Descriptor And The Specified Token Signing Certificates
    $spSSODescriptorTSCertsParent = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor/xmlnamespace:SPSSODescriptor", $ns)
     $spSSODescriptorTSCertsData = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor/xmlnamespace:SPSSODescriptor/xmlnamespace:KeyDescriptor[@use=’signing’]", $ns)

    # Process And Delete All Ocurrences Of The Token Signing Certificate Except Last Token Signing Certificate
    For ($i = $start; $i -ge $end; $i–) {
        $spSSODescriptorTSCertsParent.RemoveChild($spSSODescriptorTSCertsData[$i]) | Out-Null
    }

    # Remove The DS Signature Data From The XML Federation Metadata File
    $dsSignatureDataParent = $fedMetadataXMLMetadata.SelectNodes("/xmlnamespace:EntityDescriptor", $ns)
    $dsSignatureData = $fedMetadataXMLMetadata.SelectSingleNode("/xmlnamespace:EntityDescriptor/xmlds:Signature", $ns)
    $dsSignatureDataParent.RemoveChild($dsSignatureData) | Out-Null

    # Save The Adjusted Federation Metadata File
    $fedMetadataXMLMetadata.Save($fedMetadataXMLLastTSOnlyFilePath)

    # Display The File Paths
    Write-Host ""
    Write-Host "Original Federation Metadata File………………: $fedMetadataXMLFilePath" -ForegroundColor Magenta
    Write-Host "Adjusted Federation Metadata File (Last TS only)…: $fedMetadataXMLLastTSOnlyFilePath" -ForegroundColor Magenta
    Write-Host ""
}

This will export the original federation metadata to a file with the XML extension.

This will also export the adjusted federation metadata, with only the last Token Signing certificate, and the signature removed to a file with the XML extension.

REMARK: as mention above, ADFS signs the federation metadata with the primary Token Signing certificate to ensure its authenticity. By removing data from the federation metadata XML file, you basically break the signature as it does not match the data in the federation metadata. If the application consuming the XML federation metadata file does not check the signature, then that is not a problem. If it does check the signature, you also need to remove the “<ds:Signature>…</ds:Signature>” section/node. If the application requires a signed XML federation metadata file, then you have a problem. ADFS will only publish the last Token Signing certificate (the newest primary) after the previous primary Token Signing certificate has been removed AFTER it has become a secondary Token Signing certificate.

–

Have fun!

–

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), Certificates, Federation Metadata | Leave a Comment »

(2020-04-19) It’s That Time Again, You Need To Roll-Over The Certificates In ADFS

Posted by Jorge on 2020-04-19

This weekend I was involved in rolling over the ADFS Token Signing and Token Encryption certificates while a huge amount of application were connected using WS-Federation, SAML or OAuth. With regards to rolling over the certificates, only the WS-Federation and SAML based apps are impacted, not the OAuth apps.

Short answer: preparation, communication and automation are KEY!

–

This ADFS system was designed and implemented by me years ago. In the beginning, there were just a few apps and it grew gradually. After a moment it was starting to grow like crazy. More and more app devs smelled the federated SSO cool stuff and wanted that for their app(s). Why? Default globally supported protocols between organizations, apps, etc, and all based on federation. Supported by ADFS, many other on-premises federation systems and cloud based systems, such as e.g. Azure AD. The focus of this blog post is apps connected to ADFS as the federation provider, for both downstream identity providers and upstream service providers.

–

When I design this system, after the technology, I also designed the required processes to make sure the technology was used in the correct way. If you do not design the processes in addition to the technology, it becomes a mess and because certificates are used it will drop dead, exactly 1 year after installing/configuring it. Why will it drop dead after 1 year? The default Token Signing and Token Encryption certificates are ADFS managed and expire after 1 year. All apps not (being) able to consume to the federation metadata URL automatically will drop dead if no action is taken in time! And rushing with no process in place is a good cocktail for possible failure. If you have a handful of apps, you should be OK, but if you have 100+, or 200+ or even more apps connected to ADFS, you seriously need a process to get this done in time and correctly. Regarding the process, that ADFS has internally, please see: (2013-05-14) ADFS Managed Certificates Supporting Auto Certificate Rollover

–

Processes:

Backup/Export of the complete ADFS configuration
Provisioning of applications onto ADFS
Recertification of any connected application, keep or deprovision
Notification of expiring certificates in ADFS (about 3 months ahead of time)
Certificate change in ADFS
Validation of specified e-mail addresses against AD

–

During the onboarding of ANY application the following was recorded:

Does an application support automatic consumption of the federation metadata URL or does it support its consumption manually through an XML file?
Does an application support just 1 or 2 Token Signing certificates from an identity provider?
When an application supports the consumption of the federation metadata file, AND it supports only 1 Token Signing certificate, which certificate will it consume when it reads the federation metadata file as it contains multiple Token Signing certificates from the identity provider
E-mail addresses from at least 3 “owners”
E-mail address of either a functional mailbox or distribution list with a support team behind

–

[AD.1]

If it supports automatic consumption of federation metadata through a URL (for ADFS: /federationmetadata/2007-06/federationmetadata.xml">https://<federation service FQDN>/federationmetadata/2007-06/federationmetadata.xml) it processes the information automatically. If it does not, you may need to first export the federation metadata to an XML file to be able to import it into the application. Even though the federation metadata URL is used, it does not mean an application uses it automatically on a regular basis (e.g. every day). It is possible that a admin need to run a script, or push some button or whatever

–

[AD.2]

If an application supports 2 Token Signing certificates from an identity provider, a smooth certificate rollover is supported without ANY pain. If only 1 Token Signing certificate is supported it means, the certificate must be replaced at (nearly) the same time as the ADFS admin switches the primary and secondary Token Signing certificate

–

[AD.3]

This scenario should be very rare, but unfortunately some apps do it incorrectly. When the federation metadata from the identity provider is imported, and only 1 Token Signing certificate is used, and the federation metadata from the identity provider contains multiple Token Signing certificates, which is consumed (used) by the application? The first Token Signing certificate occurrence, or the last occurrence? If it is the last occurrence, then that is good, but the federation metadata XML file must only be imported at the same time when the switch is made in ADFS. If it is the first occurrence, then the app is not following best practice and it will break as soon as the switch in ADFS is done.

ADFS by default:

Publishes ALL Token Signing certificates in the federation metadata
The oldest Token Signing certificate is published first and the newest Token Signing certificate is published last
Switching Token Signing certificates in ADFS DOES NOT change the order of the Token Signing certificates in the federation metadata

Publishes only the primary (active) Token Encryption certificate in the federation metadata

Switching Token Encryption certificates in ADFS removes the old Token Encryption certificate from the federation metadata, and adds the new Token Encryption certificate to the federation metadata
ADFS signs the federation metadata with the primary (active) Token Signing certificate

So if the first occurrence of the Token Signing certificate is consumed, after the switch in ADFS, the only way to solve this is:

Edit the federation metadata XML file and remove the first occurrence of the Token Signing certificate (old Token Signing certificate, marked as “use=’signing’”, appears 3 times in the federation metadata XML), and keep the last occurrence (the newest) Token Signing certificate
OR
Remove the oldest Token Signing certificate as a secondary from ADFS, export the federation metadata to an XML file and import it into the application

Which option you use depends on whether or not an application checks for the signing of the federation metadata. If it does not, you can use either option, but it is easier to edit and you can keep the old Token Signing certificate as secondary if for whatever unlikely reason want to rollback (not recommended when having many applications (define “many”!) as it may turn out in a logistics nightmare

–

[AD.4]

A minimum of three e-mail addresses are required to support the yearly recertification process where a decision is made to either keep or deprovision the federation trust in ADFS. A minimum of three mail addresses as people come and people go (internally or externally), and chances are very low that all three people move at the same time (unless there is a reorganization, sigh!). If any of the listed people changes roles

–

[AD.5]

The e-mail address of a functional mailbox or distribution list with people from a (technical) support team behind it. This is mainly used by the “Certificate Change in ADFS” process. The chance of failure must be brought to a minimum by not having dependency of e-mail addresses from people, but rather have e-mail address of a functional mailbox or distribution list with people behind it. The people from a (technical) support team are responsible to updating the application with the new Token Signing when ADFS changes the certificate.

–

Now having all this information, you need to be able to store it somewhere that makes it easily manageable and provides the ability to process it through scripting (automation). Within ADFS, every single trust has a notes or description field, and the field can perfectly be used to store this information. However it is a string formatted field with a maximum of 3000 characters. I thought of the idea to implement an XML structure to be able to read from and write to it as needed. Works like magic as we can script against it too. But how about using CMDB? Well, we wanted to be certain of the up-to-date-ness of the information, we wanted to be able to script against it and we wanted it as close as possible to the trust configuration in ADFS.

–

Now, the whole certificate change in ADFS looks like something similar to:

Define "Product Backlog Items (PBI)" on the backlog, plan into sprints and assign to people
Organize initial meeting with colleagues to explain process, answer any questions and discuss PBIs
Plan meeting with (higher) management and deliver a presentation about the certificate change, discussing what, when, why, how, current state (number of trusts), risks, impact, rollback (none!), etc.
Raise an RFC to change certificates in ADFS and push to achieve the highest risk/impact category possible
Check and fix if needed e-mail addresses from application owners and support teams
Request new certificates for ADFS (SSL, Token Signing and Token Encryption)
Install all new certificates in the personal certificate store of all ADFS servers
Install the new SSL certificate in the personal certificate store of all WAP servers
Configure the new Token Signing certificate as a secondary Token Signing certificate
Configure the new Token Encryption certificate as a secondary Token Encryption certificate
Configure the new Svc Comm/SSL Certificate on all ADFS servers and WAP servers
Recheck and fix if needed e-mail addresses from application owners and support teams
Send the "First Notification" to all support teams and application owners
Notify the global service committee about the upcoming change, provide information and request to chase teams/owners
Send the "Reminder Notification" to all support teams and application owners
Switch the Token Signing/Encryption Certificate in ADFS
Send the "Switch Executed Notification" to all support teams and application owners
Guide and support support teams and application owners that request or needed guidance
Organize a closure meeting with colleagues to discuss any feedback from support teams and application owners, colleagues involved, and if applicable possible improvements for the process
Process the feedback and improvements from the closure meeting for the next time

–

End Result: SUCCESS! Oops I did it again!

–

I have done this multiple times now, and even though there is nothing to it (that’s what I think!) it is always exciting due to the huge amount of applications involved! The most difficult part is explaining this to non-technical people where you have to say things like: “there is no rollback”, “there will be issues with apps”, “fix forward only”, etc. It just scare the crap out of them and I understand that. Another one not to forget is, the support team, and sometimes even the vendor or service provideers, managing the application do not have the technical knowledge regarding federation and SSO

–

But, been there, done that, got the t-shirt, all sizes and all colours! Smile

–

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), Auto Certificate Rollover, Certificates, Export/Import, Federation Metadata, Federation Trusts | Leave a Comment »

(2019-02-22) Getting Rid Of Self-Signed Certs In Intermediate CA Store

Posted by Jorge on 2019-02-22

In the case of ADFS servers you may end up with self-signed certificates in the Intermediate CA store. Those self-signed certificates are most likely root CA certificates and those should be move to the root CA store.

After running the “Export-AdfsDiagnosticsFile” CMDlet on the (primary) ADFS server and uploading it to ADFS Help – Diagnostics Analyzer you might see something like shown below

Figure 1: Self-Signed Certificates Reported In The Intermediate CA Store By The ADFS Help Tool

–

With PowerShell you can find self-signed certificates by checking certificates and see if the subject is the same as the issuer

Get-ChildItem <Certificate Store> | ?{$_.Issuer -eq $_.Subject}

Figure 2: Self-Signed Certificates In The Intermediate CA Store

–

First you need to identity if any self-signed certificate is not a root CA certificate. In that case you can most likely remove that certificate from the intermediate CA store.

To remove a certificate from a certificate store you can use:

Get-ChildItem <Certificate Store>\<Certficate Thumbprint> | Remove-Item

–

Anything left can be moved from the intermediate CA store to the root CA store. To do that you can use the following:

$sourceCertStore = "Cert:\LocalMachine\CA"
$sourceCertStoreObject = Get-Item $sourceCertStore
$targetCertStore = "Cert:\LocalMachine\Root"
$targetCertStoreObject = Get-Item $targetCertStore
Get-ChildItem $sourceCertStore | ?{$_.Issuer -eq $_.Subject} | %{
    $thumbprint = $null
    $thumbprint = $_.Thumbprint
    $cert = $null
    $cert = Get-Item $sourceCertStore\$thumbprint
    If (!(Test-Path $targetCertStore\$thumbprint)) {
        Write-Host ""
        Write-Host "Adding Certificate With Thumbprint ‘$thumbprint’ To ‘$targetCertStore’" -ForegroundColor green
        $targetCertStoreObject.Open("ReadWrite")
        $targetCertStoreObject.Add($cert)
        $targetCertStoreObject.Close()
    } Else {
        Write-Host ""
        Write-Host "Certificate With Thumbprint ‘$thumbprint’ Already Exists In ‘$targetCertStore’" -ForegroundColor Red
    }
    If (Test-Path $targetCertStore\$thumbprint) {
        Write-Host "Removing Certificate With Thumbprint ‘$thumbprint’ From ‘$sourceCertStore’" -ForegroundColor green
        $sourceCertStoreObject.Open("ReadWrite")
        $sourceCertStoreObject.Remove($cert)
        $sourceCertStoreObject.Close()
    }
}

Figure 3: Moving Certificates From The Intermediate CA Store To The Root CA Store

–

Have fun!

–

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), Certificates, PowerShell | Leave a Comment »

(2018-10-24) Setting/Fixing The Correct Permissions On Your ADFS Certificates And/Or On The Certificate Sharing Container

Posted by Jorge on 2018-10-24

Are the permissions on any of the private keys of your certificates in use by ADFS and/or the certificate sharing container screwed up? If YES, then you can use the PowerShell code below to fix those permissions for the account the ADFS Service is running under. Make sure to test this is a test environment first!

### Function To Permission Private Key Of Custom/Non-ADFS Managed Certificates
Function permissionPrivateKey($certificate,$certType,$svcAccount) {
    $ace = $svcAccount,"Read,Synchronize","Allow"
    $machineKeysLocation = $ENV:ALLUSERSPROFILE + "\Microsoft\Crypto\RSA\MachineKeys\"
    $CertKeyFile = $certificate.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName
    $CertKeyFileFullPath = $MachineKeysLocation + $CertKeyFile
    $CertKeyFileACL = Get-Acl $CertKeyFileFullPath
    Write-Host "+++ RESULT +++" -ForeGroundColor Magenta
    $certSubject = $null
    $certSubject = $certificate.Subject
    Write-Host "Certificate Type……..: $certType" -ForegroundColor Yellow
    Write-Host "Certificate Subject…..: $certSubject" -ForegroundColor Yellow
    Write-Host ""
    Write-Host "Private Key Permissions (BEFORE)" -ForegroundColor Yellow
    $CertKeyFileACL.Access | FT @{n='[Account]’;e={$_.IdentityReference}},@{n='[Control]’;e={$_.AccessControlType}},@{n='[Permissions]’;e={$_.FileSystemRights}}
    $accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $ace
    $CertKeyFileACL.SetAccessRule($accessRule)
    $CertKeyFileACL | Set-Acl $CertKeyFileFullPath
    $CertKeyFileACL = $null
    $CertKeyFileACL = Get-Acl $CertKeyFileFullPath
     Write-Host ""
    Write-Host "Private Key Permissions (AFTER)" -ForegroundColor Yellow
    $CertKeyFileACL.Access | FT @{n='[Account]’;e={$_.IdentityReference}},@{n='[Control]’;e={$_.AccessControlType}},@{n='[Permissions]’;e={$_.FileSystemRights}}
}

### Determining Current ADFS Service Account
$adfsService = Get-WmiObject win32_service -filter "name=’ADFSSRV’"
$currentADFSServiceAccount = $adfsService.StartName

### Determining Database Type Being Used
$adfsSTS = Get-WmiObject -namespace root/ADFS -class SecurityTokenService
$configDBConnectionString = $adfsSTS.ConfigurationDatabaseConnectionString
If ($configDBConnectionString.contains("\\.\pipe\")) {
    Write-Host ""
    Write-Host "Windows Internal Database Is Being Used" -ForegroundColor Yellow
     $dbType = "WID"
    $roleADFSServer = (Get-AdfsSyncProperties).Role
    If ($roleADFSServer -eq "SecondaryComputer") {
         Write-Host ""
        Write-Host "Running On Secondary ADFS Server" -ForegroundColor Yellow
        Function portConnectionCheck($fqdnServer,$port,$timeOut) {
            $tcpPortSocket = $null
            $portConnect = $null
            $tcpPortWait = $null
            $tcpPortSocket = New-Object System.Net.Sockets.TcpClient
            $portConnect = $tcpPortSocket.BeginConnect($fqdnServer,$port,$null,$null)
            $tcpPortWait = $portConnect.AsyncWaitHandle.WaitOne($timeOut,$false)
            If(!$tcpPortWait) {
                $tcpPortSocket.Close()
                 Return "ERROR"
            } Else {
                $ErrorActionPreference = "SilentlyContinue"
                $tcpPortSocket.EndConnect($portConnect) | Out-Null
                If (!$?) {
                    Return "ERROR"
                } Else {
                    Return "SUCCESS"
                }
                 $tcpPortSocket.Close()
                $ErrorActionPreference = "Continue"
            }
        }
        $primaryADFSServer = (Get-AdfsSyncProperties).PrimaryComputerName
        $adfsWIDIsSecondary = $true
    } Else {
        Write-Host "Running On Primary ADFS Server" -ForegroundColor Yellow
        $adfsWIDIsSecondary = $false
    }
} Else {
    Write-Host "SQL Server Is Being Used" -ForegroundColor Yellow
    $dbType = "SQL"
}

### Getting ADFS Properties And Certificates
If ($dbType -eq "WID") {
    If ($adfsWIDIsSecondary) {
        $ports = 5985,443,80 # WinRM For Remote PowerShell, ADFS HTTPS, ADFS HTTP
        $connectionCheckOK = $true
        $ports | %{
            $port = $null
            $port = $_
            $connectionResult = $null
            $connectionResult = portConnectionCheck $primaryADFSServer $port 500
            If ($connectionResult -eq "ERROR") {
                $connectionCheckOK = $false
            }
        }
        If ($connectionCheckOK) {
            $primaryADFSServerSession = New-PSSession -ComputerName $primaryADFSServer
            $fedSvcConfig = Invoke-Command -Session $primaryADFSServerSession -ScriptBlock {
                $fedSvcProperties = Get-AdfsProperties
                $fedSvcCertificates = Get-AdfsCertificate
                Return $fedSvcProperties,$fedSvcCertificates
            }
            Remove-PSSession $primaryADFSServerSession
            $fedSvcProps = $fedSvcConfig[0]
            $fedSvcCerts = $fedSvcConfig[1]
        } Else {
             Write-Host ""
            Write-Host "The Primary ADFS Server IS NOT Reachable" -ForegroundColor Red
            Write-Host "Aborting…" -ForegroundColor Red
            Write-Host ""
            EXIT
        }
    } Else {
        $fedSvcProps = Get-AdfsProperties
        $fedSvcCerts = Get-AdfsCertificate
     }
}
If ($dbType -eq "SQL") {
    $fedSvcProps = Get-AdfsProperties
    $fedSvcCerts = Get-AdfsCertificate
}

### Checking If Certificate Sharing Container Has Been Configured
If ($fedSvcProps.CertificateSharingContainer) {
    Write-Host ""
    Write-Host "Certificate Sharing Container IS Configured" -ForegroundColor Yellow
    $certSharingContainerConfigured = $true
    $certSharingContainerState = "Configured"
    $certSharingContainerDN = ($fedSvcProps.CertificateSharingContainer).ToString()
} Else {
     Write-Host ""
    Write-Host "Certificate Sharing Container IS NOT Configured" -ForegroundColor Yellow
    $certSharingContainerConfigured = $false
    $certSharingContainerState = "NOT Configured"
    $certSharingContainerDN = "N.A."
}

### Checking If Custom Certificates Are Being Used Or ADFS Managed Self-Signed Certificates For Token Signing/Encryption
If ($fedSvcProps.AutoCertificateRollover -eq $false) {
    Write-Host ""
    Write-Host "ADFS Managed Self-Signed Certs ARE NOT Being Used" -ForegroundColor Yellow
    $adfsManagedCerts = $false
    $certManagement = "NON-ADFS Managed"
} ElseIf ($fedSvcProps.AutoCertificateRollover -eq $true) {
    Write-Host ""
    Write-Host "ADFS Managed Self-Signed Certs ARE Being Used" -ForegroundColor Yellow
    $adfsManagedCerts = $true
    $certManagement = "ADFS Managed"
}

### Displaying All The Info Gathered
Invoke-Command -ScriptBlock {
    Write-Host ""
    Write-Host "Database Type………………………: $dbType" -ForegroundColor Yellow
    Write-Host ""
    Write-Host "Certificate Sharing Container State…..: $certSharingContainerState" -ForegroundColor Yellow
    Write-Host ""
    Write-Host "Certificate Sharing Container DN……..: $certSharingContainerDN" -ForegroundColor Yellow
    Write-Host ""
     Write-Host "Certificate Management………………: $certManagement" -ForegroundColor Yellow
    Write-Host ""
    Write-Host "Current Service Account……………..: $currentADFSServiceAccount" -ForegroundColor Yellow
    Write-Host ""
    Write-Host "Token-Signing Certificate(s)…" -ForegroundColor Yellow
    $fedSvcTokenSigningCert = $fedSvcCerts | ?{$_.CertificateType -eq "Token-Signing"}
    $fedSvcTokenSigningCert | FT Thumbprint,@{n=’Subject’;e={$_.Certificate.Subject}},@{n=’Not Before’;e={$_.Certificate.NotBefore}},@{n=’Not After’;e={$_.Certificate.NotAfter}}
    Write-Host "Token-Encryption Certificate(s)…" -ForegroundColor Yellow
    $fedSvcTokenEncryptCert = $fedSvcCerts | ?{$_.CertificateType -eq "Token-Decrypting"}
    $fedSvcTokenEncryptCert | FT Thumbprint,@{n=’Subject’;e={$_.Certificate.Subject}},@{n=’Not Before’;e={$_.Certificate.NotBefore}},@{n=’Not After’;e={$_.Certificate.NotAfter}}
    Write-Host "Service Communications / SSL Certificate…" -ForegroundColor Yellow
    $fedSvcSvcCommCert = $fedSvcCerts | ?{$_.CertificateType -eq "Service-Communications"}
    $fedSvcSvcCommCert | FT Thumbprint,@{n=’Subject’;e={$_.Certificate.Subject}},@{n=’Not Before’;e={$_.Certificate.NotBefore}},@{n=’Not After’;e={$_.Certificate.NotAfter}}
}

### Setting Permissions On Private Key Of Custom Token Certificates
If (!$adfsManagedCerts) {
    Write-Host ""
    Write-Host "Permissioning Custom Token Certificates" -ForegroundColor Yellow
    $certStoreLocation = "Cert:\LocalMachine\My"
    $fedSvcCerts | ?{$_.CertificateType -ne "Service-Communications"} | %{
        $certificateType = $null
        $certificateType = $_.CertificateType
        $certificateThumbprint = $null
        $certificateThumbprint = $_.Thumbprint
        $certificateInStore = $null
        $certificateInStore = Get-ChildItem $($certStoreLocation + "\" + $certificateThumbprint) -ErrorAction SilentlyContinue
        If ($certificateInStore -And $certificateInStore.HasPrivateKey) {
            permissionPrivateKey $certificateInStore $certificateType $currentADFSServiceAccount
        } Else {
             Write-Host ""
            Write-Host "The Certificate With Thumbprint ‘$certificateThumbprint’ ($certificateType) Does Not Exist" -ForegroundColor Red
            Write-Host "Or" -ForegroundColor Red
            Write-Host "The Certificate With Thumbprint ‘$certificateThumbprint’ ($certificateType) Does Not Have A Private Key" -ForegroundColor Red
            Write-Host ""
        }
    }
}

### Setting Permissions On Private Key Of SSL/Service-Communication Certificate
$fedSvcCerts | ?{$_.CertificateType -eq "Service-Communications"} | %{
    $certificateType = $null
    $certificateType = $_.CertificateType
    $certificateThumbprint = $null
    $certificateThumbprint = $_.Thumbprint
     $certificateInStore = $null
    $certificateInStore = Get-ChildItem $($certStoreLocation + "\" + $certificateThumbprint) -ErrorAction SilentlyContinue
    If ($certificateInStore -And $certificateInStore.HasPrivateKey) {
        permissionPrivateKey $certificateInStore $certificateType $currentADFSServiceAccount
    } Else {
        Write-Host ""
        Write-Host "The Certificate With Thumbprint ‘$certificateThumbprint’ ($certificateType) Does Not Exist" -ForegroundColor Red
        Write-Host "Or" -ForegroundColor Red
        Write-Host "The Certificate With Thumbprint ‘$certificateThumbprint’ ($certificateType) Does Not Have A Private Key" -ForegroundColor Red
        Write-Host ""
    }
}

### If Configured Setting Permissions On Certificate Sharing Container
### WARNING: ADDS PowerShell Module Required!!! – Will Be Installed!
If ($certSharingContainerConfigured) {
    Write-Host ""
    Write-Host "Certificate Sharing Container Is Configured Used" -ForegroundColor Yellow

    # Install RSAT PowerShell Tools And Load Module
    Install-WindowsFeature RSAT-AD-Tools -IncludeAllSubFeature
     Import-Module ActiveDirectory

    # Get The Certificate Sharing Container DN, Its ACL And Present The Results Of That
    $dnPathCertSharingContainer = ($fedSvcProps.CertificateSharingContainer).ToString()
    $dnPathCertSharingContainerPath = $(Join-Path "AD:\" $dnPathCertSharingContainer)
    Write-Host ""
    Write-Host "Certificate Sharing Container Permissions (BEFORE)" -ForegroundColor Yellow
    $aclCertSharingContainer = Get-Acl $dnPathCertSharingContainerPath
    $aclCertSharingContainer.Access | FT @{n='[Account]’;e={$_.IdentityReference}},@{n='[Control]’;e={$_.AccessControlType}},@{n='[Permissions]’;e={$_.ActiveDirectoryRights}}

    # Object Class And Inheritance Scope
    $schemaIDGUIDScopedObject = [guid]"00000000-0000-0000-0000-000000000000"
    $inheritanceScope = "All"

    # Security Principal To Assign Permissions To
    $securityPrincipalAccount = $currentADFSServiceAccount
    $securityPrincipalObject = New-Object System.Security.Principal.NTAccount($securityPrincipalAccount)

    # Define ACE
    $rightsCollection = [System.DirectoryServices.ActiveDirectoryRights]::"CreateChild","Self","WriteProperty","DeleteTree","GenericRead","WriteOwner"
    $aclType = [System.Security.AccessControl.AccessControlType]::"Allow"
    $aceDefinition = $securityPrincipalObject,$rightsCollection,$aclType,$schemaIDGUIDScopedObject,$inheritanceScope
    $accessRule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($aceDefinition)

    # Set The New Access Rule
    $aclCertSharingContainer.AddAccessRule($accessRule)
    $aclCertSharingContainer | Set-Acl $dnPathCertSharingContainerPath

    # Get The Certificate Sharing Container ACL And Present The Results Of That
    Write-Host ""
    Write-Host "Certificate Sharing Container Permissions (AFTER)" -ForegroundColor Yellow
    $aclCertSharingContainer = Get-Acl $dnPathCertSharingContainerPath
    $aclCertSharingContainer.Access | FT @{n='[Account]’;e={$_.IdentityReference}},@{n='[Control]’;e={$_.AccessControlType}},@{n='[Permissions]’;e={$_.ActiveDirectoryRights}}
    $aclCertSharingContainer.Access | ?{$_.IdentityReference -eq $securityPrincipalAccount} | FT @{n='[Account]’;e={$_.IdentityReference}},@{n='[Control]’;e={$_.AccessControlType}},@{n='[Permissions]’;e={$_.ActiveDirectoryRights}}
    $aclCertSharingContainer.Access | ?{$_.IdentityReference -eq $securityPrincipalAccount}
}

–

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), Certificates, PowerShell | 1 Comment »

(2018-10-23) How Do You Know Your ADFS Server Is Lacking Permissions On Its Certificates?

Posted by Jorge on 2018-10-23

Even through the ADFS Service starts and everything “appears” to be right, NOTHING works! In the ADFS Admin Event Log you may see the following event

Figure 1: An Error In The ADFS Admin Event Log Referencing The Lack Of Permissions On The Private Key

–

There was an error in enabling endpoints of Federation Service. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.

Additional Data
Exception details:
System.ArgumentNullException: Value cannot be null.
Parameter name: certificate
    at System.IdentityModel.Tokens.X509SecurityToken..ctor(X509Certificate2 certificate, String id, Boolean clone, Boolean disposable)
    at Microsoft.IdentityServer.Service.Configuration.MSISSecurityTokenServiceConfiguration.Create(Boolean forSaml, Boolean forPassive)
    at Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.ProxyPolicyServiceHost.ConfigureWIF()
    at Microsoft.IdentityServer.Service.SecurityTokenService.MSISConfigurableServiceHost.Configure()
    at Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.ProxyPolicyServiceHost.Create()
    at Microsoft.IdentityServer.ServiceHost.STSService.StartProxyPolicyStoreService(ServiceHostManager serviceHostManager)
    at Microsoft.IdentityServer.ServiceHost.STSService.OnStartInternal(Boolean requestAdditionalTime)

–

The solution? Fix the permissions on the private keys and restart the ADFS Service on every ADFS server where the permissions were fixed

–

When the ADFS Service is finished starting your should ALWAYS see the following informational events (may be slightly different depending on the version of Windows):

Event ID 397 (WinHTTP Settings)
Event ID 349 (Administration Service)
Event ID 251 (For Every Attribute Store)
Event ID 278 (SAML Artifact)
Event ID 106 (For Every Authentication Provider (Multiple Times))
Event ID 100 (Federation Service Started Successfully)
Event ID 298 (Windows Hello For Business)
Event ID 399 (Certificate Archiving)
Event ID 386 (Certificate Expiration)
….And Last But Not Least

Figure 2: ADFS Mentioning Everything Is Correct Regarding The ADFS Certificates

–

AD FS detected that all the service certificates have appropriate access given to the AD FS service account.

–

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), Certificates | Leave a Comment »

(2017-02-17) Accessing Published Application Through Web Application Proxy With ADFS Pre-Authentication Fails

Posted by Jorge on 2017-02-17

You are using ADFS v3.0, or higher, in combination with the Web Application Proxy (WAP) to publish internal applications to the outside. Some of those applications are published with “pre-authentication” and some of those applications are published with “pass-through”.

On a device that is on the outside of your network, in a browser you enter the URL of an application that is published through the WAP with ADFS pre-authentication. The issue I’m about to explain DOES NOT occur with applications published through the WAP with pass-through.

Most likely you will hit a similar screen as the one below that is asking for Forms Based Authentication (FBA).

Figure 1: The ADFS Forms Based Authentication Screen

–

After entering the credentials you are redirected back to the application, and you end up stuck in an empty screen. When you look up at the URL, you may see something like “authToken=”.

Figure 2: After Being Redirected To The Application An Empty Screen

–

When looking in the Web Application Proxy Event Log you may find a similar event as the one below, telling you the Edge Token signing is not correct.

Figure 3: Event About An Invalid Edge Token

–

Web Application Proxy received a nonvalid edge token signature.
Error: Edge Token signature mismatch. edgeTokenHelper.ValidateTokenSignature failed: Verifying token with signature public key failed
Received token: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InNJZ1Z6ZXVQSkVnVWtkQ1BEa3VsSHF4UVY2USJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnMuaWFtdGVjLm5sIiwiaWF0IjoxNDg3MjgzNTU5LCJleHAiOjE0ODcyODcxNTksInJlbHlpbmdwYXJ0eXRydXN0aWQiOiI4NmI1OTA2MS0yZTk2LWU1MTEtODBmYy0wMDBjMjkxNDY3NWYiLCJ1cG4iOiJqb3JnZUBpYW10ZWMubmwiLCJjbGllbnRyZXFpZCI6IjM0MTljNjA4LTg4OTQtMDAwMC0zZmM3LTE5MzQ5NDg4ZDIwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTctMDItMTZUMjI6MTk6MTguMTIyWiIsInZlciI6IjEuMCJ9.L_dnLDoEQ6U8ViJ9XWBEMdagj4QsUV4emvtHiX4dik3vos3tWN_1YWvHdVO_QLi6kVqZSqdMUcya0yJ4qFifZc4R2aodrnLnn_mVDzjBJK1nyz6x_iv7LfX9kRcIdhQRJ6UoT0y9DVDnpo6b4cgu4B38ikiohu-qOcJ22TXQqYs0hgj3TCMvzFOH17dAkgL0Z1XZvGwKJDxBXPP54sRd1k8QyMMTq30kpMLi36yl8hAIIV4RTQBAVhfs6FLTBJidl7Sq3TSQwUwhf3SMNh8UNlL0CsxlKLmt1Q45NaFcFuHXCJoMjIoN_OAe21fBfyY9vrf2KygpJv77r4qRTzIYmw

Details:
Transaction ID: {3419c608-8894-0000-40c7-19349488d201}
Session ID: {3419c608-8894-0000-3fc7-19349488d201}
Published Application Name: Show My Claims (ASP.NET) (Basic)
Published Application ID: 53B426A6-162E-C09B-4D8F-62AAB4E79989
Published Application External URL: https://XXXXXXXXXXXXXXXXXXXXX/YYYYYYYYYY/
Published Backend URL: https://XXXXXXXXXXXXXXXXXXXXX/YYYYYYYYYY/
User: <Unknown>
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Device ID: <Not Applicable>
Token State: Invalid
Cookie State: NotFound
Client Request URL: https://XXXXXXXXXXXXXXXXXXXXX/YYYYYYYYYY/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InNJZ1Z6ZXVQSkVnVWtkQ1BEa3VsSHF4UVY2USJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnMuaWFtdGVjLm5sIiwiaWF0IjoxNDg3MjgzNTU5LCJleHAiOjE0ODcyODcxNTksInJlbHlpbmdwYXJ0eXRydXN0aWQiOiI4NmI1OTA2MS0yZTk2LWU1MTEtODBmYy0wMDBjMjkxNDY3NWYiLCJ1cG4iOiJqb3JnZUBpYW10ZWMubmwiLCJjbGllbnRyZXFpZCI6IjM0MTljNjA4LTg4OTQtMDAwMC0zZmM3LTE5MzQ5NDg4ZDIwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTctMDItMTZUMjI6MTk6MTguMTIyWiIsInZlciI6IjEuMCJ9.L_dnLDoEQ6U8ViJ9XWBEMdagj4QsUV4emvtHiX4dik3vos3tWN_1YWvHdVO_QLi6kVqZSqdMUcya0yJ4qFifZc4R2aodrnLnn_mVDzjBJK1nyz6x_iv7LfX9kRcIdhQRJ6UoT0y9DVDnpo6b4cgu4B38ikiohu-qOcJ22TXQqYs0hgj3TCMvzFOH17dAkgL0Z1XZvGwKJDxBXPP54sRd1k8QyMMTq30kpMLi36yl8hAIIV4RTQBAVhfs6FLTBJidl7Sq3TSQwUwhf3SMNh8UNlL0CsxlKLmt1Q45NaFcFuHXCJoMjIoN_OAe21fBfyY9vrf2KygpJv77r4qRTzIYmw&client-request-id=3419c608-8894-0000-3fc7-19349488d201
Backend Request URL: <Not Applicable>
Preauthentication Flow: PreAuthBrowser
Backend Server Authentication Mode:
State Machine State: Idle
Response Code to Client: <Not Applicable>
Response Message to Client: <Not Applicable>
Client Certificate Issuer: <Not Found>
–

When you look up the error in the first line you might find one of the following URLs:

–

In the beginning, you had to configure the WAP with the primary Token Signing certificate in use by ADFS, with the command:

Set-WebApplicationProxyConfiguration -ADFSTokenSigningCertificatePublicKey MIIFvTCCA6WgAwIBAgITPQAAAL…..

–

After the update http://support.microsoft.com/kb/2935608, you will the “ADFSTokenSigningCertificatePublicKey” property is marked as obsolete. That means you do not have to manually populate the public key of the ADFS Token Signing certificate, but rather WAP will leverage the ADFS metadata to discover the Token Signing certificates in use by ADFS.

Within ADFS you can define multiple Token Signing certificates and one of those certificates is marked as PRIMARY and all others are marked as SECONDARY. As you can see below you can see that my test/demo environment has 3 Token Signing certificates.

Figure 4: List Of Token Signing Certificates In The ADFS Console

–

When you look into the ADFS metadata (URL: /federationmetadata/2007-06/federationmetadata.xml">https://<FQDN ADFS Service>/federationmetadata/2007-06/federationmetadata.xml), you will find all the Token Signing certificates listed in the “IdPSSODescriptor” section (for the role of IdP) and in the “SPSSODescriptor” section (for the role of SP), which have been marked as “use=”signing””. As you can expect and compare it to figure 4 above, you will see (in my case!) 3 “KeyDescriptor”s, one for each Token Signing certificate in use by ADFS. ADFS will always publish all Token Signing certificates in the metadata. no matter if they’re primary or secondary. In addition, ADFS will always publish only the primary Token Encryption certificate in the metadata.

Figure 5: List Of Token Signing Certificates In The ADFS Metadata

–

Using this website you can check the certificates in the metadata and get some output you can understand. You copy the value between “<X509Certificate>…………..</X509Certificate> “ and enter that in the certificate text window.

After doing that 3 times I got (in my case!):

Figure 6: One Of The Token Signing Certificates In Use By ADFS (Marked As Secondary As Shown In Figure 4)

–

Figure 7: One Of The Token Signing Certificates In Use By ADFS (Marked As Secondary As Shown In Figure 4)

–

Figure 8: One Of The Token Signing Certificates In Use By ADFS (Marked As Primary As Shown In Figure 4)

–

As mentioned before, WAP reads the ADFS metadata and picks up the Token Signing certificates in use by ADFS. HOWEVER, it only picks the first 2 occurrences designated as “use=”signing”” as disregards all other occurrences!. Therefore in my case it reads the first and second occurrence (Figure 6 and 7) and ignores the third occurrence (Figure 8). However, when you look in Figure 4 you will see that the certificate listed in Figure 8 is the primary Token Signing certificate that is being actively used by ADFS to sign issued tokens. Because of that WAP can verify the signature of the issued Edge Token and fails with the error as shown in Figure 3.

The Figure below show you that WAP will only read the first 2 occurrences of the Token Signing certificates in the ADFS Metadata

Figure 9: WAP Reading The ADFS Metadata And Fetching The First 2 Occurrences Of The Token Signing Certificate

–

Web Application Proxy fetched certificate public key values from federation metadata successfully.
Primary key: MIIDXzCCAkegAwIBAgIQVR5qR+aSho5MH9eWFSXqWDANBgkqhkiG9w0BAQsFADAoMSYwJAYDVQQDDB1UT0tFTi5TSUdOSU5HLlNFTEYuU0lHTkVELk5FVzAeFw0xNjA1MjExMTAyNTFaFw0xODA1MDExMTAyNTFaMCgxJjAkBgNVBAMMHVRPS0VOLlNJR05JTkcuU0VMRi5TSUdORUQuTkVXMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyP5e8em3Y+2Yq57gePRoEjCymWjxozVoVlPn9JuZAQ94KLcVpFDAwJBoD1eNM587hX17WFDUqN6ZM6LMUuPiNSzdugieb+k3kQnTagkJV4vHiwo8qcBHX27DEri/pD81J+6DdiKjrqGVut6+llNP+ab0LXdsuEvoq89eGSNRoUTDHr556CFw4Y+VgwMuXwPVnJoLpj8I9Ml4kItGoBxyAA1RnWNzNBy1GKQ1vIBQxX4/aWAGqBzCs81vrpKhy0HfA/kR9eGoW3GvjJyeSXNkXMfI/5N7SAk11EPopqh6tt1XgjvbyJjiwdE1f79E3mX4ceaz2OQ4H17lYW4jtTZe4QIDAQABo4GEMIGBMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAOBgNVHQ8BAf8EBAMCBaAwMQYDVR0RBCowKIImRE5TIE5hbWU9VE9LRU4uU0lHTklORy5TRUxGLlNJR05FRC5ORVcwHQYDVR0OBBYEFODJ6In6M+5pyaZqU1ygso7MRdBoMA0GCSqGSIb3DQEBCwUAA4IBAQCddGlhNBR+HKWM9kN/EIgH6lc5HYaAzx6zdAiez3X6F/sbGzj0dSAeFrhGGMa/8S4U/lwy01z/FyDPydpoyySnVCStTRYwm1VwRKzen+YwwFWpuSZbdv/TpUm3JfPKzA6Rjaja3M+c7R+2SWZ5/lo5sJwUlhA2O+G4MZOi4F7odxa13XviOCQnnbsTM2JX8Dgue8uMe5M037xDlggeP3vNTXXChtbFTXa+S6NJksOkjL7GSC9VmHJQUPqcqyc8QJH5ynsmPtkr3txrq/HrViSEOynC3klyHOniHNitaW1TK3XHfvLK8tuNI2GL8cFmMP9hzAxANFXPA2FeESiMASJT.
Secondary key: MIIDUTCCAjmgAwIBAgIQc4D9JdgHWYxG5BMq0w06kzANBgkqhkiG9w0BAQsFADAkMSIwIAYDVQQDDBlUT0tFTi5TSUdOSU5HLlNFTEYuU0lHTkVEMB4XDTE1MDkyMTA5MDc0OVoXDTE3MDgyMjA5MDc0OVowJDEiMCAGA1UEAwwZVE9LRU4uU0lHTklORy5TRUxGLlNJR05FRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/KaQ7oQYUF7KZ7cV/PijzuxcgPurRjsoUhFOtZd0wPQz57z8dTWVa2L0Yecuu/qOXvvI5W6XtuRshhQuRpgMZohqw8/y9cVmHrLPVLsyjmSKQtXD8Xd3je+xnY01uMWW6BSB8udbPWaRKG0wnrdpFVRDVlcJKosuLAxCbwXOJbKDX27GAmYGcZSfrlCk/acTGmd7652CZKxNllPwUiX2L5zxJ0BMiEG+xurngsxqzDryrQvMz/ldzwgBZa4wQvnaoevKRTkfp/NfbY34LZxBUMNK7bwbS8dlIrGGeoGSo9q8M9QeIw5URE2CCa8/+UBZuEuorQMWQ9J5nDCzfwK+8CAwEAAaN/MH0wHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA4GA1UdDwEB/wQEAwIFoDAtBgNVHREEJjAkgiJETlMgTmFtZT1UT0tFTi5TSUdOSU5HLlNFTEYuU0lHTkVEMB0GA1UdDgQWBBQ61L+viK+SHtuwZ7OjXrARHQlFHzANBgkqhkiG9w0BAQsFAAOCAQEAr+cI1HlQUlZwxlXZchow3kWPc165qOGqu3xp2B3R1nDrMgTSlBPnIQwLCM9+X9xZ1PaQLRmPLDDOV+0CoimzvHJU+1AjdTnU82gNYBCM3ULQk+HTliilTZL3fcJE+QSOH/03TxGyopfw52v4kITGa5KsZpkemvFUnCEkgWk74D2AqDj9j0zwq5zSoJrC9eIWM8ztl3srmiFrhHmEsPSw8hbe20OdTu1xfmI/UgtnVBL2LwJnXuWpv/GgxSC41SS7F5AS2Y42Ojter6Tk5Vu1OnQwKjkJb6JvoHQcVYQaqSb4ufS1aU6kkC8U1qNAgwmv86Mhhqpf66H05UtMtKo/zg==.

–

Although this is my test/demo environment, what are the lessons learned here?

–

Please make sure to always follow the following guidelines:

Always have 1 Token Signing certificate and 1 Token Encryption certificate that are configured as primary and valid for some time (at least 2 or 3 years or more)!
Some time before the Token Signing certificate and/or the Token Encryption certificate are going to expire (e.g. 2 months before expiration) add a new Token Signing certificate and/or Token Encryption certificate (whatever is applicable) and make sure it is marked as secondary.
To all connected IdPs and connected SPs communicate you will be changing certificates, and where applicable:

Ask to check if they have updated metadata when consuming the metadata URL of your ADFS
Mail the metadata XML file containing the current and new certificates or mail the individual certificate files or just mail both

To all connected IdPs and connected SPs communicate you will be switching the certificates on a specific date

If the connected system leverages the metadata URL or metadata XML file from your ADFS and it supports 2 Token Signing certificates, the metadata can be updated right away
If the connected system leverages the metadata URL or metadata XML file from your ADFS and it supports only 1 Token Signing certificate, the metadata should be updated on the specified date
If the connected system allows the import or configuration of individual certificates and it supports at least 2 Token Signing certificates, the import or configuration of individual certificates can occur right away
If the connected system allows the import or configuration of individual certificates and it supports only 1 Token Signing certificate, the import or configuration of individual certificates should only occur on the specified date

Somewhere between 2 and 4 weeks before the certificate expires switch the certificates from primary to secondary and vice versa by configuring the new Token Signing certificate and/or Token Encryption certificate as primary
After the old Token Signing certificate and/or Token Encryption certificate (the one configured as secondary) have expired remove it from ADFS and remove it from the certificate store on every ADFS server

–

In my case the solution is: remove at least one of the secondary certs. I removed all secondaries! ending with only one as you can see below.

Figure 10: List Of Token Signing Certificates In The ADFS Console

–

On all WAP servers restart the “Web Application Proxy Service” service. You will then see the following event telling you that WAP has fetched the Token Signing certificates from ADFS

Figure 11: WAP Reading The ADFS Metadata And Fetching The First 2 Occurrences Of The Token Signing Certificate

–

Web Application Proxy fetched certificate public key values from federation metadata successfully.
Primary key: MIIFvTCCA6WgAwIBAgITPQAAALW+MGZzrC/smgAAAAAAtTANBgkqhkiG9w0BAQsFADBKMRMwEQYKCZImiZPyLGQBGRYDTkVUMRYwFAYKCZImiZPyLGQBGRYGSUFNVEVDMRswGQYDVQQDExJQS0ktUk9PVC1DQS1JQU1URUMwHhcNMTcwMTExMjI0MjM3WhcNMTkwMTExMjI0MjM3WjAlMSMwIQYDVQQDExpGUy5JQU1URUMuTkwuVE9LRU4uU0lHTklORzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMvFCaJ9uV+4PWn9x/SN9cDv1uw5iv/PAyM+0KaN9O+Z+bpC8Zg2BKG+niEnhgOL44Ju/HFq8B05ri+FTRuaF++MsbULgNspIAT/YR57O01qdHmp+/U99aAKFQGkLQzYY5H/oSvsf6KkcX/48+GdeYHJIdqaHVHoebDr/jRuFdeF+QNOhPJSa/LdFD0FkZp3E4/UbgJLNkAyI3JMfj/d0ylO/H//+/UGazfeGfCMQ25KilIjVVDypo80I9YMLuqc4SnUVLpbz907P62tL+A6bU4nsSim84zxzZ2OVqr+prCALRnQ1dGtDG1tGqGk2nCcJJrcaK6HhtalQRcypc8RZn8CAwEAAaOCAb8wggG7MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIPFnQuG8tIrgrWTDIODjlqE/NNggXmH0e1q5JkwAgFkAgEDMBMGA1UdJQQMMAoGCCsGAQUFBwMBMBEGA1UdDwEB/wQHAwUEQDAwMDAbBgkrBgEEAYI3FQoEDjAMMAoGCCsGAQUFBwMBMB0GA1UdDgQWBBRPO9BFXvhThi2Ill1j1IyuQWJVDDAlBgNVHREEHjAcghpGUy5JQU1URUMuTkwuVE9LRU4uU0lHTklORzAfBgNVHSMEGDAWgBSf9NVzUtr9IOSgZRN8SP8W+TbR5zBBBgNVHR8EOjA4MDagNKAyhjBodHRwOi8vY2RwLklBTVRFQy5ORVQvY3JsL1BLSS1ST09ULUNBLUlBTVRFQy5jcmwwgYoGCCsGAQUFBwEBBH4wfDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AuSUFNVEVDLk5FVC9vY3NwMFEGCCsGAQUFBzAChkVodHRwOi8vY3J0LklBTVRFQy5ORVQvY3J0L1IxRlNSV0RDMS5JQU1URUMuTkVUX1BLSS1ST09ULUNBLUlBTVRFQy5jcnQwDQYJKoZIhvcNAQELBQADggIBAGv392nwZGDgSq7rapUXPdDcoM69a+nsGQhdH59TYwRhHWkgcCZH7la01ZYxky0Kf9ucaAbvBDlIXP088exB44Tqal30N/umZaKpddi1l5qtyJJ2vjNbNSA8wh+iLPpNf6h3uJwGDajoSIeONnuP5imVWlH0MFNhtgcF0nTDrDiST1xzvuquWDG806NEgIZXNx2RKzEi4JHjKnMDYSaPChEF8AtUGKHKd6XfW3vtqD3PUkyTP5wF1uVJ4W7iIb9C7PcR3UlcBzs3mfUOtOUkRiKzGzPCt8agDQ+lKOXshF3vjX0oB7ZJHuGoVI9brKzI0DyxB1JJ75rvIGBIhL/CGUvYwf9tGWUr1UfXykFQGZHSw5gpNesyHlEKjfm/vmwDBDYZpkXr09/ngCJ33HKFYIdvQWZuN8GFmb14HcM5tWV+A5rJMTyAD0+ybisBIt77VZBQU3lQvdAPVeNxYePyECxPRER/Mpwmu8ctxfvkmn7a3CBa9n6G+ZPTeYLKI3vMdjUSQdCRC4/Bgupv1c9Awsf93orjaRVcu1IIfTLUlUykFTieyBzcx5jUGxvlvPNhHDDkRo9fS9eD7m/ypTEIpV2JM/0rjepE0afCva+OAlHic0T4FgZGOTguIwnAQxkVCAig3WflGRuxtqLniYllubrGkJSHQjPLT6R27QtxcxPQ.
Secondary key: <none>.

–

After these actions the application published through the WAP and configured with ADFS pre-authentication was accessible again from the outside!

–

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, Forms Based AuthN, Pre-Authentication, Security Tokens, Web Application Proxy | Leave a Comment »

(2017-01-15) Azure AD Connect Health Telling The ADFS Farm Just Dropped Dead!

Posted by Jorge on 2017-01-15

When you get any or all of the following mails from Azure AD Connect, your ADFS farm is hosed and you are in big trouble. Make sure this does NOT happen to you!

(Don’t worry, this is just my test/demo environment that was turned for the holidays)

Figure 1: E-mail From Azure AD Connect Health Mentioning The Token Signing Certificate Has Expired

–

Figure 2: E-mail From Azure AD Connect Health Mentioning The Token Encryption/Decryption Certificate Has Expired

–

Figure 3: E-mail From Azure AD Connect Health Mentioning The SSL Certificate Has Expired

–

In addition, your ADFS Admin Event Log only displays one color, RED, lots of it!

–

Posted in Active Directory Federation Services (ADFS), Azure AD Connect Health, Certificates, Windows Azure Active Directory | Leave a Comment »

(2015-10-12) Configuring System Wide Proxy Settings For ADFS To Use

Posted by Jorge on 2015-10-12

So your ADFS server requires access to the internet, what do you do? In general there are 2 options to get this done, being either directly bypassing any proxy or strait through the proxy. However, how do you tell ADFS to use a proxy?

–

Let’s first think why you would have your ADFS servers accessing the internet.

First of all, when you have a federation trust setup with a cloud-based system/application (e.g. Azure AD, Amazon Federation Web Services, etc.) that supports and publishes federation metadata, you of course want your ADFS servers to consume that federation metadata automatically, saving you manual work. This really helps you when a federation partner updates it’s Token Signing certificates when the old certificates are due to expire.

Figure 1: The Federation Metadata URL For “Microsoft Azure Active Directory”

–

Figure 2: The Federation Metadata URL For “Amazon Federation Web Services”

–

The second and last reason is to be able to perform certificate chain validation and checking the revocation status of the certificate. This of course applies to any certificate issued by a certificate authority. More information about this can be found in (2015-10-10) Certificate Chain Validation And Revocation Status Checking In ADFS.

When performing certificate chain validation of an external third-party certificate, access to the internet is required if the certificates of the root and/or the intermediate CA are not installed in the LocalMachine store.

To be able to check for the revocation status of an external third-party certificate, access to the CRL distribution points is required.

–

So you know understand why you need internet access, but the question still remains: “How will you achieve this?”

–

Achieving this by allowing the ADFS servers to bypass any proxy is the easiest way as you do not have to configure anything on the ADFS servers and you do not need to configure anything network related in addition. A huge downside is that there is no control who is accessing what on the internet. An ADFS server, which can be compared to a writeable domain controller, might misused to access compromsied web sites.

A better way is to allow access to the internet through a proxy server. This helps you to tailor what you allow to be accessed and what you do not allow to be accessed on the internet from the ADFS servers. With the knowledge of what needs to be accessible by the ADFS servers you can now configure the proxy server to only allow that. Adjustments are needed if you are federating with a new partner that publishes federation metadata or a federation partner uses a third-party certificate from a third-party CA you do not yet trust. Of course cleanup is also required if for example a federation trust is decommissioned. When configuring the proxy server prevent configuring proxy server rules through the IPs of the targeted servers on the internet. As you do not have control on what a federation partner or a certificate issuer does, which regards to IP addressing, it is not recommended to use that. I prefer to allow access based upon the hostnames, or even just domains, used in the federation metadata URL, the AIA extension URLs and the CDP extension URLs, as that is most likely not to change.

The information below applies to ADFS v2.x and higher!

–

To check the current status of the system wide proxy settings execute the following command:

NETSH WINHTTP SHOW PROXY

If you had not configured any proxy server, the output is shown below

Figure 3: No Proxy Server Defined On The System Wide Proxy Settings

–

In my test environment:

Proxy Server FQDN = GATEWAY.IAMTEC.NET
Proxy Server Port = 3128
Do not use the proxy server for the following addresses that are also available internally:

*.IAMTEC.NET <== FQDN of the internal AD domain
*.IAMTEC.NL <== FQDN of the internet domain, that’s also available internally (split DNS)
*.PARTNER.LAN <== FQDN of the internal AD domain of a sister company for which a direct connection exists
<Local Addresses> <== This only applies to NetBIOS name style addresses, and not (local) FQDNs!

–

To configure this you the following command as specified:

NETSH WINHTTP SET PROXY PROXY-SERVER="GATEWAY.IAMTEC.NET:3128" BYPASS-LIST="*.iamtec.net;*.iamtec.nl;*.partner.lan;<local>"

REMARK: “<local>” only covers NetBIOS name style addresses, and NOT FQDNs. Therefore, any FQDN needs to be explicitly specified or be covered by some wildcard FQDN. (see: MS-KBQ262981)

Figure 4: Setting Proxy Server FQDN, Port and Bypass List

–

If you ever need to remove the configured proxy settings, execute the following command:

NETSH WINHTTP RESET PROXY

Figure 5: Clearing/Removing Any Configured Proxy Settings

–

So, after configuring the proxy settings as shown in figure 4, you need to make ADFS aware of those new settings. The configuration needs to be done on every ADFS STS server, and it is activated by just restarting the ADFS service:

NET STOP ADFSSRV

NET START ADFSSRV

or if you are a PowerShell geek

Restart-Service ADFSSRV

Now, when you have a look in the ADFS Admins Event Log you will find the following event ID, which tells you that ADFS has picked up the new proxy settings

Figure 6: ADFS Loading The HTTP Proxy Configuration From WinHTTP

–

By default, ADFS starts the trust monitoring cycle every 24 hours (1440 minutes). When you check the ADFS Properties (Get-ADFSProperties), you will most likely see (if you did not change it!) that the “MonitoringInterval” property is configured with the value 1440. If you temporarily lower that value to, let’s say, 1 minute, you can actively see if the configured proxy settings are working and if ADFS is able to pass through the proxy.

To lower the Trust Monitoring Cycle to 1 minute, execute the following command on the (primary) ADFS server:

Set-AdfsProperties -MonitoringInterval 1

When ADFS initiates the trust monitoring cycle, you will see the following event ID.

Figure 7: ADFS Initiated The Trust Monitoring Cycle

–

When ADFS completes the trust monitoring cycle, you will see the following event ID.

Figure 8: ADFS Completed The Trust Monitoring Cycle

–

Somewhere between those 2 event IDs you may find event IDs, but that depends if it was successful or not. If a specific federation trust is configured with a federation metadata URL and at least monitoring is enabled, you will not find any event ID if the monitoring was successful for that federation trust. However, if for some reason the monitoring was not successful for a specific federation trust, you will find the following event ID stating that monitoring failed.

Figure 9: Failed Trust Monitoring For A Federation Trust

–

Of course you want to confirm it is actually been monitored successful. Therefore, to figure out, if monitoring is successful or not, you can use the following PowerShell command:

For CP Trusts: Get-AdfsClaimsProviderTrust | ?{$_.Enabled -eq $true -And $_.MetadataUrl -ne $null -And $_.MonitoringEnabled -eq $true} | %{"`nName………………: "+$_.Name+"`nLastMonitoredTime…..: "+$_.LastMonitoredTime+"`nLastUpdateTime……..: "+$_.LastUpdateTime}

For RP Trusts: Get-ADFSRelyingPartyTrust | ?{$_.Enabled -eq $true -And $_.MetadataUrl -ne $null -And $_.MonitoringEnabled -eq $true} | %{"`nName………………: "+$_.Name+"`nLastMonitoredTime…..: "+$_.LastMonitoredTime+"`nLastUpdateTime……..: "+$_.LastUpdateTime}

Figure 9: Retrieving ‘Last Monitored Time’ And ‘Last Update Time’ For Every Applicable Federation Trust

–

Be aware, that the ‘LastMonitoredTime’ is updated, whether or not the monitoring was successful. Therefore, if you see an updated ‘LastMonitoredTime’ and no event ID exist for that specific federation trust (as shown in picture 9), you can be sure that access through the proxy using the configured proxy settings is successful!

Remember that the ‘LastUpdateTime’ will only be updated, if there is something new to update!

–

Now, when you have finished testing, make sure to reconfigure the monitoring interval back to its original value (or the value you had configured)

Set-AdfsProperties -MonitoringInterval 1440

–

Posted in Active Directory Federation Services (ADFS), Certificates, Federation Metadata, Federation Trusts, System Wide Proxy Settings | 1 Comment »

(2015-10-10) Certificate Chain Validation And Revocation Status Checking In ADFS

Posted by Jorge on 2015-10-10

Within ADFS federation trusts can be configured with one or more Token Signing certificates and/or one Token Encryption certification. More information about certificates used in ADFS can be found through the following blog post (2013-05-13) Certificates Used In Active Directory Federation Services (ADFS) v2.x (also applies to ADFS v3 and ADFS v4!).

–

For every certificate used, certificate chain validation is done if the certificate was issued by a CA. It does not apply to self-signed certificates as there is no chain. For CA issued certificates, certificate chain validation is performed online through the URL(s) specified in the AIA extension of the certificate, or offline if the certificates in the chain of the certificate are configured in the Local Machine stores for Root CAs and Intermediate CAs.

Figure 1: The Authority Information Access (AIA) Extension Of A CA Issued Certificate

–

In addition, the revocation status of the certificate is checked through the URL(s) specified in the CDP extension of the certificate and/or the AIA extension of the certificate when OCSP is being used. This of course only applies to any certificate issued by a certificate authority. It does not apply to self-signed certificates.

Figure 2: The CRL Distribution Points (CDP) Extension Of A CA Issued Certificate

–

Revocation status checking of a certificate used in a particular federation trust (Claims Provider Trust or Relying Party Trust) depends on the setting configured for the certificate type used by the trust (e.g. Token Signing and/or Token Encryption). Both the Token Signing certificate and the Token Encryption certificate have their own revocation status checking setting, and both support the following settings:

CheckChain –> Check online revocation status for every certificate that is part of the certificate chain
CheckChainCacheOnly –> Check offline revocation status for every certificate that is part of the certificate chain
CheckChainExcludeRoot (DEFAULT) –> Check online revocation status for every certificate that is part of the certificate chain, except for the certificate of the root CA
CheckChainExcludeRootCacheOnly –> Check offline revocation status for every certificate that is part of the certificate chain, except for the certificate of the root CA
CheckEndCert –> Check online revocation status for only the end certificate being used
CheckEndCertCacheOnly –> Check offline revocation status for only the end certificate being used
None –> Do not perform any (online or offline) revocation status checking

–

Certificate chain validation can be done either offline or online, and that also applies certificate revocation status checking. For certificate revocation status checking, either being performed online or offline, access to the CRL distribution points is still required.

Certificate chain validation checks the validity of the complete chain. Certificate revocation status checking checks for the revocation status of the certificates used, depending on the configured settings. It is also possible to fully disable certificate revocation status checking. But think again! You are relying on (third-party) certificates to increase the assurance of the certificates being used in some federation trusts, therefore checking the revocation status is a good idea! When disabling it or weakening it, the purpose of using certificates is defeated. So, why would you still disable certificate revocation status checking? Let me guess, the ADFS server(s) do not have any external network (e.g. internet) connectivity and can therefore not access the CRL distribution points. Remember that the federation ecosystem heavily depends on certificates, and that checking the validity of those certificates is of utmost importance. There *I* would prefer to have the ADFS servers accessing the internet to check certificate revocation lists. Any risk mitigation actions available to protect the ADFS from malicious web sites? Yes, there is and that’s for the next blog post!

–

Posted in Active Directory Federation Services (ADFS), Certificates | 1 Comment »

(2014-05-12) Automatic Metadata Exchange From Shibboleth To ADFS Fails With Multiple Encryption Certificates

Posted by Jorge on 2014-05-12

For ADFS I have explained in this blog post, from a process perspective, what you need to do when you need to replace any of the certificates in use by ADFS. Shibboleth is yet another federated identity solution and it is open source. You can read more about it here and here.

–

Like ADFS, Shibboleth (and any other federated identity solution) uses certificates for Token Signing and Token Encryption and you can either just use one certificate for both or use 2 individual certificates, one for each operation.

–

[Scenario 1] If you use just one certificate for both operations, your Shibboleth configuration (in ..\Shibboleth-SP\etc\shibboleth\shibboleth2.xml) regarding certificates may be similar to:

–

[Scenario 2] If you use just one certificate for each operation, your Shibboleth configuration (in ..\Shibboleth-SP\etc\shibboleth\shibboleth2.xml) regarding certificates may be similar to:

–

REMARK: it is not mandatory to specify ‘use’ or keyname. When no ‘use’ is specified explicitly, it is both used for signing and encryption. When no ‘keyname’ is specified it uses the common name of the certificate as the keyname.

–

Based upon the configuration above in Shibboleth, you will the following in ADFS (or something similar)

Figure 1: The Federation Trust With A Token Encryption Certificate

–

Figure 2: The Federation Trust With One Token Signing Certificate

–

Shibboleth supports the publication of information regarding the federated identity solution into the federated identity solution metadata. ADFS in turn supports the consumption of automatic published metadata. So you are good to go and you have no worries when the federation partner using Shibboleth needs to replace the current certificates! Wrong!.

–

After the federation partner using Shibboleth configures Shibboleth using one of the following ways, or something similar:

[Scenario 1] If you use just one certificate for both operations, your Shibboleth configuration (in ..\Shibboleth-SP\etc\shibboleth\shibboleth2.xml) regarding certificates may be similar to:

–

[Scenario 2] If you use just one certificate for each operation, your Shibboleth configuration (in ..\Shibboleth-SP\etc\shibboleth\shibboleth2.xml) regarding certificates may be similar to:

–

…you will start to see the following error in ADFS

[A] the federation trust with a red cross and not updating itself while automatic monitoring and updating is enabled

Figure 3: A Federation Trust In Error

–

Figure 4: An Outdated Federation Trust With Automatic Monitoring/Updating

–

[B] the next time you manually update the metadata through the GUI of the CP or RP Trust representing the Shibboleth federated identity solution

Figure 5: Manually Updating The Metadata Of A Shibboleth Based Federated Identity Solution Using The ADFS GUI Results In Error

–

An unexpected error occurred during an attempt to process the federation metadata. Verify that the federation metadata is correct and try again.
Error message: MSIS7508: The metadata contains unexpected data. Conflicting encryption certificates were found in the RoleDescriptors needed to represent a service provider role.

–

[C] the next time you manually update the metadata through PowerShell of the CP or RP Trust representing the Shibboleth federated identity solution

Figure 6: Manually Updating The Metadata Of A Shibboleth Based Federated Identity Solution Using The ADFS CMDlets Results In Error

–

Update-ADFSRelyingPartyTrust : MSIS7508: The metadata contains unexpected data. Conflicting encryption certificates were found in the RoleDescriptors needed to represent a service provider role.
At line:1 char:29
+ Update-ADFSRelyingPartyTrust <<<< -TargetName "Shibboleth Service Provider (R1FSMBSV4)"
+ CategoryInfo : NotSpecified: (Microsoft.Ident…lyingPartyTrust:RelyingPartyTrust) [Update-ADFSRelyingPartyTrust], MetadataProcessingException
+ FullyQualifiedErrorId : MSIS7508,Microsoft.IdentityServer.PowerShell.Commands.UpdateRelyingPartyTrustCommand

–

The reason this happens is that ADFS does not support (accept) the consumption of (automatic) metadata from another federated identity solution that publishes two Token Encryption certificates. Shibboleth publishes as many Token Encryption certificates as you have configured it with. This may also apply to other federated identity solutions. This is not a problem if multiple Token Signing certificates are published.

–

The first thing you need to do is download the metadata to a file using the federation metadata URL as specified in the federation trust (see figure 2). Save the metadata to a file called "METADATA_<TRUST NAME>_ORG.TXT". Then make a copy of that file and name it "METADATA_<TRUST NAME>_MODIFIED.TXT". Now open and edit the last file.

If "scenario 1" applies, 2 so called CredentialResolvers have been defined in Shibboleth and in the metadata you will find 2 "<md:KeyDescriptor>" sections. Depending on the way it has been configured you may not be able to distinguish between the current certificate(s) and the new certificate(s). For each "<md:KeyDescriptor>" section copy the data/value in the "<ds:X509Certificate>" section into the decoding window on a website such as http://www.sslshopper.com/certificate-decoder.html or http://redkestrel.co.uk/products/decoder/. After doing that for each certificate you will see something such as shown in the pictures below. Now you will be able to determine which certificate is the current certificate and which is the new certificate.

Figure 7: Decoded Data Of A Certificate (This Is The Current/Old Certificate)

–

Figure 8: Decoded Data Of A Certificate(This Is The New Certificate)

–

For the current/oldest certificate configure the <md:KeyDescriptor> (figure 9) as <md:KeyDescriptor use="signing"> (figure 10)

Figure 9: KeyDescriptor Without Use Specification – Old Certificate Used For Both Signing And Encryption (Before)

–

Figure 10: KeyDescriptor With Use Specification – Old Certificate Used For Signing Only (After)

–

For the newest certificate create a full copy of the <md:KeyDescriptor>

For the newest certificate configure the first <md:KeyDescriptor> (figure 11) as <md:KeyDescriptor use="signing"> (figure 12)

Figure 11: KeyDescriptor Without Use Specification – New Certificate Used For Both Signing And Encryption (Before)

–

Figure 12: KeyDescriptor With Use Specification – New Certificate Used For Signing Only (After)

–

For the newest certificate configure the second <md:KeyDescriptor> (figure 13) as <md:KeyDescriptor use="encryption"> (figure 14)

Figure 13: KeyDescriptor Without Use Specification – New Certificate Used For Both Signing And Encryption (Before)

–

Figure 14: KeyDescriptor With Use Specification – New Certificate Used For Encryption Only (After)

–

After performing the changes save "METADATA_<TRUST NAME>_MODIFIED.TXT"

–

Now it is time to manually update the CP or RP trust with the new metadata.

First execute: Add-PsSnapin microsoft.adfs.powershell (ADFS v2.0) OR Import-Module ADFS (ADFS v2.x and higher)

For CP Trusts execute: Update-ADFSClaimsProviderTrust -TargetName "<CP Trust Name>" -MetadataFile "<Path to file METADATA_<TRUST NAME>_MODIFIED.TXT>"

For RP Trusts execute: Update-ADFSRelyingPartyTrust -TargetName "<RP Trust Name>" -MetadataFile "<Path to file METADATA_<TRUST NAME>_MODIFIED.TXT>"

–

After executing the update command you most likely will see the following. The yellow errors can be ignored.

Figure 15: Manually Updating The Metadata Of The Federation Trust

–

When checking the federation trust you will that the certificates have been updated

Figure 16: The Federation Trust With A New Token Encryption Certificate

–

Figure 17: The Federation Trust With Two Token Signing Certificates (One Old And One New)

–

Be aware that the errors on figure 4, 5 and 6 will continue to occur until the Shibboleth administrator has removed the multiple definitions of a Token Encryption certificate. As soon as that happens, the metadata can be updated again automatically!

When updating the metadata manually you will again see:

Figure 18: Manually Updating The Metadata Of A Shibboleth Based Federated Identity Solution Using The ADFS GUI Results In Messaging Stating Incompatibilities

–

If "scenario 2" applies, 4 so called CredentialResolvers have been defined in Shibboleth and in the metadata you will find 4 "<md:KeyDescriptor>" sections. Depending on the way it has been configured you may not be able to distinguish between the current certificate(s) and the new certificate(s). For each "<md:KeyDescriptor>" section copy the data/value in the "<ds:X509Certificate>" section into the decoding window on a website such as http://www.sslshopper.com/certificate-decoder.html or http://redkestrel.co.uk/products/decoder/. After doing that for each certificate you will see something such as shown in the pictures 7 and 8. Now you will be able to determine which certificate is the current certificate and which is the new certificate.

–

For the current/oldest encryption certificate remove its <md:KeyDescriptor use="encryption"> section. You are now left with three <md:KeyDescriptor> sections where each already has a use defined. Save the file and update the federation trust accordingly as explained above. Be aware that the errors on figure 4, 5 and 6 will continue to occur until the Shibboleth administrator has removed the multiple definitions of a Token Encryption certificate. As soon as that happens, the metadata can be updated again automatically!

–

Posted in Active Directory Federation Services (ADFS), Certificates, Federation Metadata, Security Token Service (STS), Shibboleth | Leave a Comment »

« Previous Entries

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!

For Ad Free Blog

Social Media

Profiles

Statistics

Other Cool Blogs

Interesting Places To Visit

The Knowledge Archives

RSS Links

Email Subscription

Categories

Archive for the ‘Certificates’ Category

(2020-07-08) Federation Metadata From ADFS Adjusted To Support “Broken” Applications

(2020-04-19) It’s That Time Again, You Need To Roll-Over The Certificates In ADFS

(2019-02-22) Getting Rid Of Self-Signed Certs In Intermediate CA Store

(2018-10-24) Setting/Fixing The Correct Permissions On Your ADFS Certificates And/Or On The Certificate Sharing Container

(2018-10-23) How Do You Know Your ADFS Server Is Lacking Permissions On Its Certificates?

(2017-02-17) Accessing Published Application Through Web Application Proxy With ADFS Pre-Authentication Fails

(2017-01-15) Azure AD Connect Health Telling The ADFS Farm Just Dropped Dead!

When you get any or all of the following mails from Azure AD Connect, your ADFS farm is hosed and you are in big trouble. Make sure this does NOT happen to you!

(2015-10-12) Configuring System Wide Proxy Settings For ADFS To Use

(2015-10-10) Certificate Chain Validation And Revocation Status Checking In ADFS

(2014-05-12) Automatic Metadata Exchange From Shibboleth To ADFS Fails With Multiple Encryption Certificates

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!

For Ad Free Blog

Social Media

Profiles

Statistics

Other Cool Blogs

Interesting Places To Visit

The Knowledge Archives

RSS Links

Email Subscription

Categories

Archive for the ‘Certificates’ Category

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

When you get any or all of the following mails from Azure AD Connect, your ADFS farm is hosed and you are in big trouble. Make sure this does NOT happen to you!

Share this:

Share this:

Share this:

Share this: