Multi Tenanted ADFS in Office 365 - Public Key of ADFS Certificate?

Hi! :)

I am making use of a solution to manually federate domains with the same ADFS instance on Office 365 (Source:

I am using the below powershell script:

$Domain = ''
# Create new federated enabled domain
New-Msoldomain -Name $Domain -Authentication Federated 
# Retrieve and set TXT record in DNS
$TXTrecord = (Get-MsolDomainVerificationDns -domain $Domain).label -replace "\..*",""
$TXTrecord = 'MS=' + $txtrecord
# ADFS Federation Settings
$Brand = 'Contoso'
$ActiveSO = ''
$PLUri = ''
$IssuerUri = "http://$Domain/adfs/services/trust/" # NOTICE the $Domain variable
$Metadata = ''
# Public key of the ADFS code signing certificate, this is an example
$Cert = "MIIC3jCCAcaGAwIBAiIQZy18ai4/1qNKekSKawAD2jBNAgkqhkiG9w0BAQsFADArMSkwJwYDVRRDEyBBREZTIFNpZ25bpmcgLSBzdHNud1Vya29ubG..SHORTENED..fXunm6+Tp0e11zorVaeA4nu46fAKnf9+E/Iumw1GcC/Kca4T+8SaWp8Zjip74zCY4zPOQ" 
# Confirm domains TXT record in DNS and set federation properties
Confirm-MsolDomain –DomainName $Domain -FederationBrandName $brand -PassiveLogOnUri $PLUri -SigningCertificate $Cert -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveSO -LogOffUri $PLUri -MetadataExchangeUri $metadata

Open in new window

My question is simple... what is the public key of the ADFS code signing certficate and how can I find this? I have been able to run all the above commands separately without specifying a certificate and the adfs redirect works, just the token is rejected for the user probably because I left -SigningCertificate $Cert blank ;-)

Any ideas?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Brian MurphyIT ArchitectCommented:
The public key, or ADFS in a 365 migration still uses MS Crypto.

You should be able to browse your Local Machine store and get the "Hash".

That "hash" is the public key.

Unless you have the private key as well and it would show up and allow an export to PFX file.

Powershell use
Set-Location Cert:\CurrentUser\My
Get-ChildItem | Format-Table Subject, FriendlyName, Thumbprint -AutoSize


You can navigate in the digital signature certificate store on your computer. The certificate store maps to the Windows PowerShell Cert: drive. The following example shows how to use Set-Location (cd) and Get-Childitem (dir, ls) to navigate the Cert: drive.

PS C:\> cd cert:
PS cert:\> dir
PS C:\> cd localmachine
PS C:\> dir

Thumbprint                                Subject
----------                                -------
F88015D3F98479E1DA553D24FD42BA3F43886AEF  O=C&W HKT SecureSomethingoranother CA SGC Root, C=hk
F44095C238AC73FC4F77BF8F98DF70F8F091BC52  CN=Class 3TS Primary CA, O=Certplus, C=FR

PS C:\> get-childitem F88015D3F98479E1DA553D24FD42BA3F43886AEF

Now, there are several ways to do this.... For one, you can bind a HASH to a service like SQL.... Using Registry Keys.

So if you have one FQDN Named Certificate you can bind it to several services using that HASH and corresponding registry key.
Restart the service.



CMD Prompt
certutil /?


With that said, you probably already have this covered.  But....

Do all your UPN Suffixes and PRIMARY SMTP EMAIL addresses match in the AD Domain.
tegeniusAuthor Commented:
So I set the certfificate hash using Set-MsolDomainAuthentication -domainname "" -SigningCertificate "hash of the certificate"

I get the below error when signing in to office 365 where it redirects to ADFS, asks for my username and password. If I type it in wrong it knows, if I type it in correctly I get sent to the below error:

Sign In
Sorry, but we’re having trouble with signing you in.
We've received a bad request.

Timestamp: 2015-10-07 11:39:51Z
AADSTS50008: SAML token is invalid.

The timestamp is an hour out from my time zone. Is that a 365 problem or have I used the wrong hash? :D
tegeniusAuthor Commented:
Looking at the use of the $cert variable in this example, it seems the certificate code is a lot longer than the hash?

In their example:

Active Protection takes the fight to cryptojacking

While there were several headline-grabbing ransomware attacks during in 2017, another big threat started appearing at the same time that didn’t get the same coverage – illicit cryptomining.

tegeniusAuthor Commented:
Ok. fixed that bit... I think it is because the timestamp is an hour out...

Timestamp: 2015-10-07 12:04:27Z

IT's 13:04 here.

Is the timezone problem Office 365 side?
Brian MurphyIT ArchitectCommented:
Apologies for delay.  What is your authentication method?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Brian MurphyIT ArchitectCommented:
tegeniusAuthor Commented:
You sir... are a legend. The fix for the SAML error was Issue 3 under

I simply opened up a session with MSOL I.e. Connect-Msolservice and the like...

I used Set-MsolADFSContext to connect to my ADFS server

After using the custom powershell script in my original question, I had failed to run "Update-MsolFederatedDomain -DomainName -SupportMultipleDomain"

This fixed the problem.

Brian MurphyIT ArchitectCommented:
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Office 365

From novice to tech pro — start learning today.