Seven Layers delivers comprehensive, dependable, and cost-effective solutions tailored to our clients’ needs and budgets. We offer cutting edge defensive security strategies to provide you with the ability to protect key systems and information – and can pair those with traditional information technology services to keep your business up and running, so you can focus on the business that is important to you.

    We provide penetration testing services and vulnerability assessments for peace of mind, risk management, and regulatory compliance. And because your employees are often your first line of defense - or weakness – we offer employee education in computer security and corporate security policies.

    Our support services cover your full suite of end user desktops, in-house servers, cloud-based servers, and cloud services. This includes seamless support for employees in all locations, whether they are in corporate offices, or are remote users. We will manage and develop content management systems, customized software and web applications, as well as working with off the shelf applications.


     

    It seems lately we've been doing a number of Exchange migrations and we're seeing the dreaded "Security Alert".  In a nutshell, the server has an internal name which does not match the external name to which the certificate was assigned.  When the Outlook client is remote to the server, everything works as it should.  But when the Outlook client is internal, the user receives the following error:

     

    Certificate Warning

    There are several ways to solve this problem and I think a UCC certificate is one approach but I prefer the option with zero expense.

    This is a little trickier than my typical post and I want to spell out what I'm trying to accomplish.

    My internal server name is:  Microsoft

    Internally, the Fully Qualified Domain Name (FQDN) for my server is:  Microsoft.HateMe.local

    Externally, the FQDN for my server with matching certificate is:  Microsoft.HatesMe.com

    With elevated privileges, launch the Exchange Management Shell.

    With the following commands, we are changing the identity from the mismatched internal name to the matched external name.  In the forth command, we are enabling Outlook Anywhere which may or may not already be enabled.  It won't hurt anything if it's enabled.  In one instance, I seem to recall seeing a prompt regarding SSL Offloading, select or enter No.  It should finish and allow you to move to the final command.

    Set-ClientAccessServer -Identity "Microsoft" –AutodiscoverServiceInternalURI https://Microsoft.HatesMe.com/autodiscover/autodiscover.xml

    Set-WebServicesVirtualDirectory -Identity "Microsoft\EWS (Default Web Site)" –InternalUrl  https://Microsoft.HatesMe.com/EWS/Exchange.asmx
     
    Set-OABVirtualDirectory -Identity “Microsoft\OAB (Default Web Site)” -InternalURL https://Microsoft.HatesMe.com/OAB

    Enable-OutlookAnywhere -Server Microsoft -ExternalHostname “Microsoft.HatesMe.com” -ClientAuthenticationMethod “NTLM”

    Set-ActiveSyncVirtualDirectory -Identity “Microsoft\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://Microsoft.HatesMe.com/Microsoft-Server-Activesync

    This is definitely one of the more sophisticated tasks I've written and you definitely want to test this out in a controlled environment prior to executing it on your production server.

    An SSL certificate is cheap and you can easily setup on a test machine.  I've double checked my work but it comes with no warranty -- you've been warned.  ;)


    Cybersecurity solutions for small businesses.

    info@sevenlayers.com
    877.468.0911

    © 2021 Seven Layer Networks, Inc. | All rights reserved.