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:
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?
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 $metadataMy 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?
ASKER
So I set the certfificate hash using Set-MsolDomainAuthenticati
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
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
ASKER
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 = "MIIEQzCCAyugAwIBAgIKYQm1C
CZImiZPyLGQBGRYDY29tMR0wGw
MBAGA1UEAxMJRGVudmVyLUNBMB
MFowIzEhMB8GA1UEAxMYZGVudm
hkiG9w0BAQEFAAOCAQ8AMIIBCg
UXJs2weW/4cMniVNYGanLABVuq
yT7E4n35GOFxf8OVUy38VI1BrF
r8jpDZa/eLcMV/1lFifpNXz2v1
gYNhvZln2Z/M2Xwy5oh21lAjzb
tgPXTphJsg6+2606nlJqflsxjp
UjCCAU4wDgYDVR0PAQH/BAQDAg
CIP16AeH74RRh62DOIaW7CWEl7
RGMSiX+JPfV4zEGxeXGeFXm1kz
N/ntwjA/BgNVHR8EODA2MDSgMq
Y29tL0NEUC9EZW52ZXItQ0EuY3
AoYuaHR0cDovL3BraS53b29kZ3
dDATBgNVHSUEDDAKBggrBgEFBQ
BwMBMA0GCSqGSIb3DQEBBQUAA4
q4QZzAtef7viv4By6RI4xvbjap
0nXFrIS6onvPQDAxXLgz8b/Ynl
hirX2Q+27LBEvf9pmG/Nc7WXlm
PnB9VyrfTjPutLI4GqSuaMqrYx
hb32hqVF14uxWC4DNO5ccaqTKx
https://msdn.microsoft.com/en-us/library/azure/dn194112.aspx
In their example:
$cert = "MIIEQzCCAyugAwIBAgIKYQm1C
CZImiZPyLGQBGRYDY29tMR0wGw
MBAGA1UEAxMJRGVudmVyLUNBMB
MFowIzEhMB8GA1UEAxMYZGVudm
hkiG9w0BAQEFAAOCAQ8AMIIBCg
UXJs2weW/4cMniVNYGanLABVuq
yT7E4n35GOFxf8OVUy38VI1BrF
r8jpDZa/eLcMV/1lFifpNXz2v1
gYNhvZln2Z/M2Xwy5oh21lAjzb
tgPXTphJsg6+2606nlJqflsxjp
UjCCAU4wDgYDVR0PAQH/BAQDAg
CIP16AeH74RRh62DOIaW7CWEl7
RGMSiX+JPfV4zEGxeXGeFXm1kz
N/ntwjA/BgNVHR8EODA2MDSgMq
Y29tL0NEUC9EZW52ZXItQ0EuY3
AoYuaHR0cDovL3BraS53b29kZ3
dDATBgNVHSUEDDAKBggrBgEFBQ
BwMBMA0GCSqGSIb3DQEBBQUAA4
q4QZzAtef7viv4By6RI4xvbjap
0nXFrIS6onvPQDAxXLgz8b/Ynl
hirX2Q+27LBEvf9pmG/Nc7WXlm
PnB9VyrfTjPutLI4GqSuaMqrYx
hb32hqVF14uxWC4DNO5ccaqTKx
ASKER
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?
Timestamp: 2015-10-07 12:04:27Z
IT's 13:04 here.
Is the timezone problem Office 365 side?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I believe that is an Azure Code
https://msdn.microsoft.com/en-us/library/azure/jj571618.aspx
https://msdn.microsoft.com/en-us/library/azure/jj571618.aspx
ASKER
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-MsolFederatedDomai
This fixed the problem.
Cheers!
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-MsolFederatedDomai
This fixed the problem.
Cheers!
Awesome.
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
---------- -------
F88015D3F98479E1DA553D24FD
F44095C238AC73FC4F77BF8F98
PS C:\> get-childitem F88015D3F98479E1DA553D24FD
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.