This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(150.4, 91%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EM%3C/text%3E%3C/svg%3E)
Two wap and two adfs 3.0 in use with exchange 2013 for owa and ecp. It has been working fine.
Exchange 2016 was added to the organization for migration. However, pointing the dns identifier to 2016 sso doesn't work. Only regular prompt is received.
Since 2016 uses the same organization settings as 2013 not sure what is missing. Token signing cert thumbprint matches. Had adfs authentication set to true (with others false) on virtual directory as mentioned in the article below and that didn't work.
https://learn.microsoft.com/en-us/exchange/clients/outlook-on-the-web/ad-fs-claims-based-auth?view=exchserver-2019
Also, imported the cert to 2016 box root store. didn't work.
Thanks.
What do you mean by "dns identifier" points to 2016 SSO?
What is the AdfsAudienceUris set to?
Get-OrganizationConfig |FL *ADFS*
The 2016 virtual dirs need to be defined there
https://learn.microsoft.com/en-us/powershell/module/exchange/set-organizationconfig?view=exchange-ps
https://learn.microsoft.com/en-us/exchange/clients/outlook-on-the-web/ad-fs-claims-based-auth?view=exchserver-2019#step-6-configure-the-exchange-organization-to-use-ad-fs-authentication
Set-OrganizationConfig -AdfsIssuer https://<FederationServiceName>/adfs/ls/ -AdfsAudienceUris "<OotwURL>","<EACURL>" -AdfsSignCertificateThumbprint "
<Thumbprint>"
I meant the current owa url points to the CAS of 2013 and when we set it to point to 2016 (by modifying the local host dns record).
Since the 2013 and 2016 are within the same organization, the get organization config shows "https://email.mycompany.com/owa, https://email.mycompany.com/ecp" and the thumbprint also matches with the one from token signing cert.
Right now it works when pointed to 2013. Users can access mailboxes in 2016. But when the dns is set to point to 2016 cas it doesn't work. We want to retire 2013 so need to ensure everything point to 2013.
typo above: We want to retire 2013 so need to ensure everything point to 2016.
and you did an iireset after making the change to the auth on the 2016 server and OWA/ECP were both changed? Sorry for the dumb questions!
Yes sir. No worries. I am the dumb one here asking for help. lol
Ok, it sounds like you have everything covered actually. I have made this change myself and the only modification needed was the virtual dirs on 2016 were correctly defined and it worked.
What prompt are you seeing? A Basic auth prompt or FBA? for both OWA and EAC, you get the same prompt?
Would it be crazy to reset everything again?
When this was first tried, windows authentication and adfsauthentication were turned on. (forms based were turned off). This mimicked the settings that is on exchange 2013.
That took to the sso page but errored afterwards. The url of the error had "wrongaudienceUriorBadSigningCert". So, verified the thumbprint and even imported the token signing cert to the root store of exchange 2016. That threw an error. Didn't even get to adfs sso page.
When only adfsauthentication was turned on, i believe that resulted in error. I will touch base with our email guy and try the process again.
so, with windows authentication enabled and adfs enabled, we get a dialog box for login (not sso). If only adfs authentication then it errors out HTTP 401.
Consider doing a SAML trace from your browser when you test this and ensure its being redirected to the ADFS servers
It seems exchange 2016 isn't even attempting to reach out to adfs. I didn't see anything in adfs logs. If only the adfs authentication is set to true and iisreset performed it throws in http 401. A bit weird that it co exists with 2013 and the owa and ecp virtual directories permissions match with that of 2013 (2013 had windows authentication set to true as well but it goes to adfs sso directly).
Marking this as answer since, re-applying
Set-OrganizationConfig -AdfsIssuer https://<FederationServiceName>/adfs/ls/ -AdfsAudienceUris "<OotwURL>","<EACURL>" -AdfsSignCertificateThumbprint "
with same set of values that were already in place worked. Apparentlly, something flipped and re-application of the command set it right again.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(28.799999999999997, 82%, 12%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EEY%3C/text%3E%3C/svg%3E)
Hi,
Can you post the result of " Get-OrganizationConfig |FL ADFS "?
I just wonder if you add "/" at the end of each url:
The inclusion of the trailing slash / in the URL examples shown below is intentional. It’s important to ensure that both the AD FS relying party trusts and Exchange Audience URI’s are identical. This means the AD FS relying party trusts and Exchange Audience URI’s should both have or both emit the trailing slashes in their URLs. The examples in this section contain the trailing /’s after any url ending with “owa” ( /owa/) or “ecp” (/ecp/).
If an Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
The Uri don't have a trailing / in both exchange audience URI and the ADFS trust. This works with exchange 2013 which is current environment. We introduced exchange 2016 to the exchange organization and it co-exists with 2013. If "mail.mycompany.com" points to 2013 it works. But if we point it to 2016 it doesn't.
AdfsIssuer : https://sso.mycompany.com/adfs/ls
AdfsAudienceUris : {https://mail.mycompany.com/owa, https://mail.mycompany.com/ecp}
AdfsSignCertificateThumbprints : {xxxxx}
AdfsEncryptCertificateThumbprint : System.Collections.Hashtable
fyi, the thumbprint matches the thumbprint of the cert in use (again, 2013 has no issues with these settings).
I have the slashes for both.
I think that article meant " should both have or both OMIT the trailing slashes in their URLs. " lol
Did you do a SAML trace from a workstation to see if it ever attempts to connect to ADFS?
When it fails, what do the IISlogs on the 2016 server show?
With both adfs and windows authentication set to true, ran a fiddler to a point where it prompted with the authentication dialog box (non-sso).
Fiddler has HTTP 200 tunnel to the mail.mycompany.com:443 and then HTTPS 401 mail.mycompany.com (host) and /owa (URL).
And with only adfs authentication set to true and rest false, it is the same trace. A couple of tunnels to mail.mycompany.com:443 and then HTTPS 401 for host mail.mycompany.com and url /owa.
It is not redirecting to adfs.
A couple more thoughts:
Did you set the ECP and OWA dirs in the correct order per that article
What CU is this?
Can your re-run this command? and add the / at for the ADFSAudienceUris
Set-OrganizationConfig -AdfsIssuer https://<FederationServiceName>/adfs/ls/ -AdfsAudienceUris "<OotwURL>","<EACURL>" -AdfsSignCertificateThumbprint "
So, ran a test federation trust and that returned an error "Attempted to get delegation token, but token came back as null". Hoping this will lead somewhere
maybe not related? The exchange 2013 is hybrid but we don't have the mailboxes in cloud. That seems to point to trust with azure ad?
Hesitant to change the uri with / since current 2013 uses sso and it works with that environment.
build is 2106.2 which is CU18.
We changed the adfs authorization to ecp first (didn't iisreset) and owa after that. Once both done issreset was performed.
Yea, that trust test is for federation trusts so not related :(
Here are my virt dir auth settings on the 2016 servers - which sound like match yours:
InternalAuthenticationMethods : {Adfs}
BasicAuthentication : False
WindowsAuthentication : False
DigestAuthentication : False
FormsAuthentication : False
LiveIdAuthentication : False
AdfsAuthentication : True
OAuthAuthentication : False
ExternalAuthenticationMethods : {Fba}
Yes, we tried having the adfs authentication to true and rest to false. That results in http 401. When windows authentication is set to true along with adfs we get a login prompt for windows authentication.
A very weird part is, the first time the email admin set it up he had the virtual directories match the same as exchange 2013. He modified his PC host file to point to new exchange 2016. It did land up with adfs sso page. But threw an error "X-FEServer" and the error url had "WrongAudienceUriOrBadSigning". We noticed the token signing cert wasn't present in the root store. Imported that. But around that point it stopped going to sso altogether.
By the way, thank you very much for sticking around. Much appreciated.
so, since no mailboxes were in 2016 we decided to reset the owa and ecp virtual directories. Not able to login to exchange 2016 through owa and ecp. Had to set windows authentication to true to log in.
But back to where we were with the reset.
Have a real quick question. So, it wasn't working for exchange 2016 but the 2013 cas were fine. But when one of the cas was rebooted, it started showing the same behavior. Any insight into what 2016 might have changed globally for all? Apparenlty, 2013 was working because it hadn't taken the settings before which it did apparently after reboot.
Any idea on what would 2016 cause for sso to be broken? 2013 CAS were working fine. But when one of 2013 was rebooted it stopped working. Apparently, something change after 2016 was introduced into the organization.
Are you sure the org settings weren't messed with at all?
So now the 2013 servers are getting a 401 when trying to use ADFS auth? And nothing in the ADFS logs? i.e. its not even trying to redirect the client to use ADFS?
I think its something within the org settings, too. Since a working cas would not redirect after a restart one thing that jumps to mind is the cert location settings in Organization config for adfs.
<serviceCertificate><certificateReference x509FindType="FindByThumbprint"
findValue="System.Collections.Hashtable" storeLocation="LocalMachine" storeName="My" /></serviceCertificate>
Since the signing cert is located in root, I wonder if storeName need to change to root or the signing cert moved to personal store? The technet article references using set-location to root "Set-Location Cert:\LocalMachine\Root; Get-ChildItem | Sort-Object Subject". Just curious if executing this would change the location in org settings and fix it?
Do you have access to the ADFS server?
Can you check the Relying Party properties for EAC and OWA?
Specifically the "Endpoints" and "Identifiers"
Make sure that OWA and EAC URL endpoints match ( including any trailing /) what you have set for the ADFSaudienceURIs in the Exchange org config.
Yes, those match. Didn’t make any change in the adfs. One exchange 2013 that wasn’t rebooted still works so we know it’s working.
I am curious about the cert store in for adfs in organization config. Wondering if that setting was changed which affected the adfs auth upon iisreset or reboot of server. Don’t have a lab to test that.
Apparently,
Set-OrganizationConfig -AdfsIssuer https://<FederationServiceName>/adfs/ls/ -AdfsAudienceUris "<OotwURL>","<EACURL>" -AdfsSignCertificateThumbprint "
with the same set of values that were already in place did the job. Apparently, something flipped within organization configuration after the introduction of exchange 2016 and the same settings had to be re-applied.
Glad its fixed! Have a great week.
Yes, was quite a conundrum. Glad it is fixed. Thank you very much for your insight and help. Have a great week!