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: http://www.ruudborst.nl/multi-tenant-azure-federation-without-dirsync-aadsync-aadconnect-fim/)

I am using the below powershell script:

$Domain = 'customer.com'
 
# 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 = 'https://sts.contoso.com/adfs/services/trust/2005/usernamemixed'
$PLUri = 'https://sts.contoso.com/adfs/ls/'
$IssuerUri = "http://$Domain/adfs/services/trust/" # NOTICE the $Domain variable
$Metadata = 'https://sts.contoso.com/adfs/services/trust/mex'
 
# 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?
tegeniusAsked:
Who is Participating?

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

x
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

OR

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
(EXAMPLE OUTPUT)

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.

ALSO

Certutil.exe

CMD Prompt
certutil /?

NOW

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 "domain.com" -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?

https://msdn.microsoft.com/en-us/library/azure/dn194112.aspx

In their example:

$cert = "MIIEQzCCAyugAwIBAgIKYQm1CwAAAAAAEDANBgkqhkiG9w0BAQUFADBIMRMwEQYK
CZImiZPyLGQBGRYDY29tMR0wGwYKCZImiZPyLGQBGRYNd29vZGdyb3ZlYmFuazES
MBAGA1UEAxMJRGVudmVyLUNBMB4XDTEwMDExMDA2NDEwMFoXDTExMTExMTAxMTM0
MFowIzEhMB8GA1UEAxMYZGVudmVyLndvb2Rncm92ZWJhbmsuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApUaiuxFkfXf9O5kUSpxOBSBFhjFirBb3
UXJs2weW/4cMniVNYGanLABVuqltfRHqWz6WZF/98VbqfCaETBaKu/QggcuhMoBc
yT7E4n35GOFxf8OVUy38VI1BrFon/crs8IUc0pK3qKG0n4rsCRwnpxoEPar0MiSP
r8jpDZa/eLcMV/1lFifpNXz2v1wKWYRKXrvg1sLJyABSRoAZShxaMcXehS0egmiP
gYNhvZln2Z/M2Xwy5oh21lAjzbrW2eLmsqr1OTsFO497CBsuoWS4KQUbxf7hVj3T
tgPXTphJsg6+2606nlJqflsxjpH90ucendRZVPJ1Vs83yMUcPUyA+QIDAQABo4IB
UjCCAU4wDgYDVR0PAQH/BAQDAgWgMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcV
CIP16AeH74RRh62DOIaW7CWEl7BNJ4bS92uFwqxxAgFkAgECMB0GA1UdDgQWBBQ6
RGMSiX+JPfV4zEGxeXGeFXm1kzAfBgNVHSMEGDAWgBSZzCX7ueHUBH7PY6wVldwn
N/ntwjA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vcGtpLndvb2Rncm92ZWJhbmsu
Y29tL0NEUC9EZW52ZXItQ0EuY3JsMEoGCCsGAQUFBwEBBD4wPDA6BggrBgEFBQcw
AoYuaHR0cDovL3BraS53b29kZ3JvdmViYW5rLmNvbS9BSUEvRGVudmVyLUNBLmNy
dDATBgNVHSUEDDAKBggrBgEFBQcDATAbBgkrBgEEAYI3FQoEDjAMMAoGCCsGAQUF
BwMBMA0GCSqGSIb3DQEBBQUAA4IBAQCVaxdQ2nO5cpo0AQL+Pk/hXs3JOe+cRD1F
q4QZzAtef7viv4By6RI4xvbjap5iRs3wzWBuRdTT4zKcTZrUkBuyo3rxkmy8dzbh
0nXFrIS6onvPQDAxXLgz8b/YnlfnpCH1t/FoH6lqjmsiESYtfj43j8epDg91OhvQ
hirX2Q+27LBEvf9pmG/Nc7WXlm38UI1tpHw9lYqEOde2bxz7o2hgLcZg8ptJx4ci
PnB9VyrfTjPutLI4GqSuaMqrYxzjVplNkVMV3ZjJc2Jh8mLiaY7iPwRO3zPMs+Vn
hb32hqVF14uxWC4DNO5ccaqTKxUKH0LngEo9GItFhjxGlcg0fwI0"
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?

https://support.microsoft.com/en-us/kb/3015526

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 https://support.microsoft.com/en-us/kb/3015526

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 domain.co.uk -SupportMultipleDomain"

This fixed the problem.

Cheers!
Brian MurphyIT ArchitectCommented:
Awesome.
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.