Certificate Warnings when upgrading to Exchange 2016

Because Exchange Server runs most of its configuration at an "Organisation Level" adding new Exchange Servers to an existing Exchange Environment can be a difficult challenge to ensure users get a seamless experience.  When adding new Exchange Servers to an organisation (such as Exchange 2016) in an existing Exchange 2013 organisation, the new Exchange 2016 server will immediately start advertising its SCP Autodiscover record and other internalURLs such as the MapiVirtualDirectory.

Whilst this does not cause direct issues to Exchange Resources, it will present certificate warnings on Outlook clients as the default Self Signed certificate will not be trusted on the Outlook clients.

Outlook Clients (if they are in the same Active Directory site) as the Autodiscover Site Scope will immediately start picking up the new Exchange server and communicating with it - hence generating certificate warnings such as the one below.

 

As an Exchange Administrator, your first task after building the new server is to immediately install a valid trusted certificate on your new Exchange server and update the Autodiscover SCP record on the new ClientAccessService with the Set-ClientAccessService cmdlet.  It is then very important to update all other URLs such as the MapiVirtualDirectory, Outlook Anywhere etc.

Changing the values for your new Exchange 2013/2016 servers however will not stop the certificate warnings from being displayed to users right away however.  Even though you update your Records, Outlook clients will continue receiving the old records for some time as shown in the screenshot below.

This occurs as when the Exchange 2016 server is first built, your Exchange 2013 servers will cache in the IIS AppPool these original records.  Your Exchange 2013 servers will continue to return via Autodiscover the record of the Exchange 2016 FQDN that does not match the name on the digital certificate.

To force your Exchange 2013 servers to start forcing the correct name immediately, an iisreset is required on all Exchange 2013 servers in the same Active Directory site as the new Exchange 2016 server.  This will cause a slight disruption for users.

See the issue?

• As soon as your new Exchange 2016 server is installed, users will begin getting certificate warnings.
• To quickly update the certificate and names of the Exchange Web Services, the iisreset on the Exchange 2013 servers will cause a slight outage.

Make sure you plan for this in your Exchange 2016 rollout.  Let users know in advance to ignore the certificate warning which will be displayed after the first Exchange 2016 server is built.  This will reduce the load on your companies service desk.

The Danger of the Local Administrator Account

The local administrator account resides on every Windows Server and is usually in an enabled state.  This account is a major security vulnerability and is commonly prone to hacking attempts.

Security flaws with this account include:

• This account cannot be locked out and does not adhere to local or domain account lockout password policies.  This allows brute force attacks to be conducted against the account.
• The local administrator account is a well known SID, it always begins with S-1-5- and end with -500.  There are also tools allowing you to login with a SID rather then an account name so an attacker could launch a brute force without knowing the account!

Quote from Microsoft https://technet.microsoft.com/en-us/library/jj852165.aspx"

"The built-in Administrator account cannot be locked out no matter how many failed logons it accrues, which makes it a prime target for brute-force attacks that attempt to guess passwords. Also, this account has a well-known security identifier (SID), and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to log on. All other accounts that are members of the Administrator's group have the safeguard of locking out the account if the number of failed logons exceeds its configured maximum."

If security if your top concern, my recommendation is to disable this account and always create a new Administrator account regardless if it is the default domain Administrator account or default local Administrator account.

Need IT Support in Perth, give me a call now on 08 9468 7575