asked on
Security alert in Outlook for office 365 Certificate
I have a client that moved to Office 365 from on-premise Exchange 2010. They are using AD Sync so the old Exchange server is still online. When they open Outlook, they get a security alert for Outlook.office365.com - the security certificate for this site had been revoked. When I click to view details it shows it is issued by digicert and is valid until 8/1/2020.
This only happens when opening Outlook inside the network. laptops get this message inside the network but not outside.
Autodiscover is working properly. On the on-premise server I run Get-ClientAccessServer |select AutoDiscoverServiceInterna
How do I stop that security alert from coming up
This only happens when opening Outlook inside the network. laptops get this message inside the network but not outside.
Autodiscover is working properly. On the on-premise server I run Get-ClientAccessServer |select AutoDiscoverServiceInterna
How do I stop that security alert from coming up
Microsoft OfficeExchangeMicrosoft 365
Last Comment
Brian Murphy
ASKER
As I mentioned I can ping autodiscover.domain.com and it returns Office 365 autodiscover name autod.ms-acdc.office.com
This is a root domain issue. Auto Discover can still work fine.
Since this is a domain joined machine, the user is located in the same domain, and the machine is on the corporate network why was it looking at the root domain.
Outlook client will initially do the SCP lookup, on-premises Exchange cannot answer for Office 365 mailboxes. Outlook then goes off and does the DNS chase down to find the Office 365 Autodiscover URL.
In a hybrid configuration the external Autodiscover namespace must point back to the on-premises Exchange infrastructure and not to Office 365.
You probably just need to disable "AutoDiscover Root Domain Lookup" by setting these registry keys on downlevel clients
HKEY_CURRENT_USER\Software
HKEY_CURRENT_USER\Software
I recommend changing this on one down level client and simply testing my theory. Then, you can use GPO.
This can be done with GPO as well just need to have a central repository for with each version of ADMX/ADML files per version you have distributed to all internal clients.
Or, you can track down the IIS binding on possibly one or more DC's where you have SSL/TLS binding but that particular certificate is expired.
For example, remove autodiscover from FQDN and what does domain.com resolve to "internal".
The IP(s) of your DC's?
Since this is a domain joined machine, the user is located in the same domain, and the machine is on the corporate network why was it looking at the root domain.
Outlook client will initially do the SCP lookup, on-premises Exchange cannot answer for Office 365 mailboxes. Outlook then goes off and does the DNS chase down to find the Office 365 Autodiscover URL.
In a hybrid configuration the external Autodiscover namespace must point back to the on-premises Exchange infrastructure and not to Office 365.
You probably just need to disable "AutoDiscover Root Domain Lookup" by setting these registry keys on downlevel clients
HKEY_CURRENT_USER\Software
HKEY_CURRENT_USER\Software
I recommend changing this on one down level client and simply testing my theory. Then, you can use GPO.
This can be done with GPO as well just need to have a central repository for with each version of ADMX/ADML files per version you have distributed to all internal clients.
Or, you can track down the IIS binding on possibly one or more DC's where you have SSL/TLS binding but that particular certificate is expired.
For example, remove autodiscover from FQDN and what does domain.com resolve to "internal".
The IP(s) of your DC's?
You may be having an issue getting to the CRL from inside your network. If you View Certificate, you should be able to see the CRL path from the details on the certificate. See here: https://www.digicert.com/util/utility-test-ocsp-and-crl-access-from-a-server.htm
There is a policy setting to have Outlook not attempt to download the CRL for the certificate, this will reduce security but may be a good workaround for you temporarily. See Outlook - Security - Cryptography - Signature Status dialog box - Retreiving CRLs. If you enable this policy settings you can set the option to "Never retrieve the CRL". Alternatively you can set the registry key HLCU\software\policies\mic
There is a policy setting to have Outlook not attempt to download the CRL for the certificate, this will reduce security but may be a good workaround for you temporarily. See Outlook - Security - Cryptography - Signature Status dialog box - Retreiving CRLs. If you enable this policy settings you can set the option to "Never retrieve the CRL". Alternatively you can set the registry key HLCU\software\policies\mic
ASKER
I got a new certificate for the on-premise server however I still have the security alert come up when Outlook is opened.
The certificate is for remote.domain.com and autodiscover.domain.com
I had made these changes during the cutover to Office 365:
set-WebServicesVirtualDire
Set-WebServicesVirtualDire
Set-ClientAccessServer –Identity servername –AutoDiscoverServiceIntern
autodiscover.domain.com points to autodiscover.outlook.com
After installing the certificate and still getting the alerts I set them back to point to https://remote.domain.com,,,, inside the network remote.domain.com points to the internal server
It sill did not work. I changed autodiscover to point to the internal server and it still is not working.
In hybrid mode what should these settings be?
The certificate is for remote.domain.com and autodiscover.domain.com
I had made these changes during the cutover to Office 365:
set-WebServicesVirtualDire
Set-WebServicesVirtualDire
Set-ClientAccessServer –Identity servername –AutoDiscoverServiceIntern
autodiscover.domain.com points to autodiscover.outlook.com
After installing the certificate and still getting the alerts I set them back to point to https://remote.domain.com,,,, inside the network remote.domain.com points to the internal server
It sill did not work. I changed autodiscover to point to the internal server and it still is not working.
In hybrid mode what should these settings be?
This is a root domain issue. Auto Discover can still work fine.
Since this is a domain joined machine, the user is located in the same domain, and the machine is on the corporate network why was it looking at the root domain.
Outlook client will initially do the SCP lookup, on-premises Exchange cannot answer for Office 365 mailboxes. Outlook then goes off and does the DNS chase down to find the Office 365 Autodiscover URL.
Making those changes above is not going to keep Outlook from searching for the root domain.
Like I stated earlier, from one client simply run the connectivity test and you should see it trying to connect to domain.com and finding something.
You can see this if you run the "Client Connectivity Wizard" using either Outlook or Remote Tool
https://testconnectivity.microsoft.com/
From Exchange
To Run the Exchange Analyzer tests in Support and Recovery Assistant, go to Advanced Diagnostic > Exchange Online > Check Exchange Online network connectivity > Yes.
Check Outlook Connection Status. Press CTRL key and right-click the Outlook icon in the notification area > select Test Connectivity....
Internally, your machines are domain joined. To the AD Domain, not referring to FQDN.
You could have something internal, still, that is responding on domain.com (just the root).
You can easily rule out this theory by my previous comment.
You probably just need to disable "AutoDiscover Root Domain Lookup" by setting these registry keys on downlevel clients
HKEY_CURRENT_USER\Software
HKEY_CURRENT_USER\Software
Reboot
Retest
If the certificate error goes away you know now that you have either IIS running on a DC with a root certificate bound - for whatever reason - or something else. Easy to test and rule out.
Since this is a domain joined machine, the user is located in the same domain, and the machine is on the corporate network why was it looking at the root domain.
Outlook client will initially do the SCP lookup, on-premises Exchange cannot answer for Office 365 mailboxes. Outlook then goes off and does the DNS chase down to find the Office 365 Autodiscover URL.
Making those changes above is not going to keep Outlook from searching for the root domain.
Like I stated earlier, from one client simply run the connectivity test and you should see it trying to connect to domain.com and finding something.
You can see this if you run the "Client Connectivity Wizard" using either Outlook or Remote Tool
https://testconnectivity.microsoft.com/
From Exchange
To Run the Exchange Analyzer tests in Support and Recovery Assistant, go to Advanced Diagnostic > Exchange Online > Check Exchange Online network connectivity > Yes.
Check Outlook Connection Status. Press CTRL key and right-click the Outlook icon in the notification area > select Test Connectivity....
Internally, your machines are domain joined. To the AD Domain, not referring to FQDN.
You could have something internal, still, that is responding on domain.com (just the root).
You can easily rule out this theory by my previous comment.
You probably just need to disable "AutoDiscover Root Domain Lookup" by setting these registry keys on downlevel clients
HKEY_CURRENT_USER\Software
HKEY_CURRENT_USER\Software
Reboot
Retest
If the certificate error goes away you know now that you have either IIS running on a DC with a root certificate bound - for whatever reason - or something else. Easy to test and rule out.
ASKER
Autodiscover test comes back with no errors.
When you say "disable" registry keys do you mean delete them?
Still not sure why it says the certificate for this site has been revoked when it is issued to Outlook.com and is valid until 2020
When you say "disable" registry keys do you mean delete them?
Still not sure why it says the certificate for this site has been revoked when it is issued to Outlook.com and is valid until 2020
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Registry settings did not work. I am working on a terminal server so I can not reboot now but I logged off and back on. I assume that is enough since these registry keys are under HKEY_CURRENT_USER
ASKER
There is one more registry setting needed. I found this on another site and it appears to have worked
Hkey current user\software\policies\mic
Not sure if this is all that is needed or if I needed Brain's registry settings also. I may test that later but for now I am happy to have this resolved
Hkey current user\software\policies\mic
Not sure if this is all that is needed or if I needed Brain's registry settings also. I may test that later but for now I am happy to have this resolved
Glad it is working. Simplest solution often works. I came at this from the registry perspective to help eliminate "all the above" being I'm not in the "driver's seat". If you want to find the "root cause" we can troubleshoot further but need to start a separate thread. There is a reason why this is happening although if your ultimate goal is "cutover" then might be unnecessary.
In your local DNS server if you have yourdomain.com zone then make sure you have the autodiscover.yourdomain.co