Outlook security popups on Exchange: Frustrating but fixable – TechGenix


In every Exchange organization, there comes a day when you will have users complain about security popups they are getting on Outlook. Sometimes these are related to the following:

  • Certificates invalid or expired.
  • Incorrect URLs set in Exchange.
  • Bindings not set to the new SSL certificate that was imported.
  • Certificates on load balancers like F5 or Kemp where virtual or physical certificates also expired or are incorrectly assigned to a rule.
  • Internal CA certificates used and causing popups externally.
  • Free SSL certificate with a CA not trusted.

For the most part, Outlook security popups cause a lot of user frustration, but they are simple to fix. Sometimes new admins get overwhelmed in the real world because they say “it didn’t do this in my lab,” but this is how we all learn. Other times, we get busy and our SSL certificates expire and we forget to renew them in time and then users get popups because of the old certificate.

Here are typical prompts and errors your users might get:

Outlook security popups

Outlook security popups

Outlook security popups and misconfigured Exchange server

Another scenario is when IT admins build new Exchange servers and don’t configure them immediately. So, they come in the next day with the helpdesk phones going crazy because the clients are looking at the new server but it has not been configured like the old servers or doesn’t have an SSL certificate imported yet. The big problem is the load balancers. I am also guilty of this one. Your security department issues you with a new certificate and you go and update everything, reboot the servers but forgot the one place everyone connects to and that is the F5 or Kemp load balancer or whatever device you use in your environment. Now you have the CIO asking you why you didn’t update that one? It happens.

READ  Chip ‘fingerprint’ technology for secure transactions - The Hindu

Another common problem is the use of internal CAs that are not recognized on the Internet so users get Outlook security popups or certificate warnings on Outlook on the Web.

Bindings in IIS (Internet Information Systems) also seem to be missed by IT admins. The default website for Exchange on port 443 uses the SSL certificate and the backend website on port 444 also makes use of the SSL cert. If you renew the certificate or add a new one, it does not always update the bindings.

But everything seems fine

There seems to be another problem floating around at the moment. I had a customer who also had a complaint about popups and I have seen it on the forums a few times now. You go and check everything, all the URLs are set, the bindings in IIS are correct. Servers are rebooted from start to finish but yet your end-users say they are getting Outlook security popups. You check the Offline Address Book (OAB) to make sure that is correct or if you have legacy public folder databases, but everything there is fine.

So, you go and check the permissions on the virtual directories and change everything to NTLM, restart the server, and hope that it is that, that will fix the errors, but still the Outlook security popups occur. The command for reference to set Outlook anywhere to use NTLM is as follows:

Set-OutlookAnywhere -ExternalHostname mail.domain.com -InternalHostname mail.domain.com -ExternalClientsRequireSsl $true -InternalClientsRequireSsl $true -DefaultAuthenticationMethod NTLM

Fix: Enable OAuth

So, here is the real question: Is the below a fix or problem with a mix in code with Office 365 and on-premises Exchange? My client reported that after enabling OAuth, the errors and prompts listed above went away. OK, so how do you check if OAuth is enabled? First, run the command below to check:

READ  Look to retail for an example of DevOps success - CIO Dive

Get-OrganizationConfig | fl *oauth*

As you can see, you are checking the organization config so this change is systemwide. Once you run the command it will most likely be set to false. The setting you are looking for is as per below:

OAuth2ClientProfileEnabled

To enable this setting, you need to run the following command:

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

This now sets the ClientProfile to Enabled. You will need to either do an IISReset or reboot the server for the changes to take effect and wait for replication. As I mentioned, doing this should mean the errors and security prompts listed above should be gone.

Outlook security popups: Problems with Exchange 2010 with Exchange 2016

One final problem that you might face before you set this is if you are running in coexistence with Exchange 2010 and Exchange 2016 and the connection from Exchange 2016 to Exchange 2010 is not proxied across. If you do run across this issue, it might be that you need to log it with Microsoft as this might be happening on certain cumulative updates (CU) on Exchange 2016 or with a mixture of Exchange 2010 SP3 and Exchange 2016. Only they will be able to advise on this. This doesn’t seem to affect everyone. I have a coexistence running in my Azure lab and I cannot produce the same error, but when running Fiddler against my connection to my client that was affected, I could see the 401 errors happening, which didn’t make sense.

Featured image: Shutterstock


Post Views:
3



report this ad

READ  Analysis | How 'Cybersovereignty' Splits the Once World Wide Web - Washington Post



Read Next




READ SOURCE

LEAVE A REPLY

Please enter your comment!
Please enter your name here