ADFS Certificate Renewal

I don’t usually do this, but I love this post so much I needed to tell my readers about it. ADFS has 3 certificates assigned to it, and it’s uncommon for the token-signing and token-decrypting certificates to be trusted, 3rd party certs. They are usually left as self-signed certs. Their use scenario doesn’t demand that 3rd party certs are used, and in all honesty using these would provide no tangible benefit. So whenever I deploy ADFS, only the Service Communications certificate uses a trusted 3rd party cert.

The renewal of these self-signed certificates can be a pain and can easily be forgotten until it’s too late, so whenever I deploy ADFS for a customer, I always set the duration of these certificates to 100 years, using this handy guide!

http://www.expta.com/2015/03/how-to-update-certificates-for-ad-fs-30.html

Advertisements

Exchange 2013 Hybrid – Content was blocked because it was not signed by a valid security certificate

Hello again. The last few days have given me lots of new things to do, so apologies if you are being inundated with blog posts!

So today I went to enable a new Exchange 2013 Hybrid configuration. I used the Start Menu launcher for ‘Exchange Administrative Centre’, which to be honest I don’t usually do. This took me to https://localhost/ecp/?ExchClientVer=15. I then went to Hybrid and enabled the Hybrid Configuration. I logged into Office 365 and was greeted by this friendly message of doom:

Content was blocked because it was not signed by a valid security certificate

This error is quite easily solved; do not use localhost as the server name when you access the ECP. Use your client access namespace instead. For example, if my CAS name was mail.misstech.co.uk, I would browse to https://mail.misstech.co.uk/ecp/?ExchClientVer=15.

Just be sure to put outlook.office365.com and your CAS name into your Intranet Zone too or you’ll then get an error about Cookies!

412 - Cookies are disabled

Thanks for reading!

Exchange 2013 installation and annoying Outlook certificate Security Alert

I know, I know….why am I blabbering on about an Exchange version which is 3 years old?! The answer is because I still install it all the time, mainly for the purposes of Exchange Hybrid deployments. And this is probably old news to most of you, but if you didn’t know, Exchange 2013 can be particularly annoying when you first install it.

Once the install is completed, an SCP record is registered in Active Directory for your shiny new server (which still has all of its out of the box settings). If you faff around at all after the installation has completed, drinking tea and making merry at the water cooler, you will find that your users start moaning at you about the certificate errors they are receiving.

Outlook Certificate Error

This is because your new server has, without your consent, started merrily responding to Autodiscover and EWS requests made through Active Directory. This new server doesn’t have your public certificate installed, and also is using internal server names for it’s URLs.

What you need to do on Exchange 2013 to get around this is:

  • Install your trusted 3rd party SAN/wildcard certificate and assign it to the IIS service. Restart IIS
  • Configure, as a minimum, the Autodiscover, EWS and OAB Internal URLs to reflect your Exchange namespace
    • set-webservicesvirtualdirectory -identity ‘Servername\EWS (default web site)’ -internalurl ‘https://namespace.domain.com/ews/exchange.asmx’
    • set-oabvirtualdirectory -identity ‘Servername\OAB (default web site)’ -internalurl ‘https://namespace.domain.com/OAB’
    • set-clientaccessserver -server servername -autodiscoverserviceinternaluri ‘https://autodiscover.domain.com/autodiscover/autodiscover.xml’

This should mitigate the problem while you actually configure your server. Unfortunately it’s just part of the way Autodiscovery works, and personally I’d rather it was this way round, rather than having to remember to enable the SCP record at some point. Because knowing me, I’d forget.

You could also mitigate this problem by following the guidance on my blog post about Autodiscover optimisation and disabling SCP lookups temporarily for your users. If you are going to be using Hybrid in the future, this may be desirable anyway.

 

Script to change Exchange internal URLs

All Exchange consultants will have been through this situation at least once now; a customer is using a split namespace in their Exchange environment with a .local name internally, and due to the new requirements for purchasing SAN certificates, they can no longer purchase certificates with a .local name on them. One way of remedying this is to change all the Exchange internal URLs to use the public name, and add in an internal DNS zone and record to point the public name at the Exchange environment.

Changing the URLs for multiple virtual directories and servers can be a pain. There are many scripts like this out there on the internet, but I frankenstein’ed this one to fit the needs I had. I wanted it to prompt for the server name, public FQDN and autodiscover FQDN and then change the directories on that particular server to reflect the names I had entered. I also love simplicity, so I wanted the most simple script possible. If you wanted to change this to do the external URL’s, then just do a find and replace internal with external! This script will work on Exchange 2010 and 2013.

Also, if you are using a wildcard certificate, be sure to run the below command to force the name match, otherwise you may get certificate errors on your clients!

Set-OutlookProvider -identity EXPR -certprincipalname msstd:*.domain.com

Here is the script I use:

#get variables
write-host "Set Exchange 2010 Internal URLS" –Foregroundcolor Yellow
$urlpath = Read-Host "Type CAS Array FQDN starting with https://"
$autodpath = Read-Hosts "Type Autodiscover FQDN starting with https://"
$CASserver = Read-Host "Type internal server FQDN"
#change urls for all internal directories
Set-AutodiscoverVirtualDirectory -Identity "$CASserver\Autodiscover (default web site)" –internalurl “$autodpath/autodiscover/autodiscover.xml”
Set-ClientAccessServer –Identity "$CASserver" –AutodiscoverServiceInternalUri “$autodpath/autodiscover/autodiscover.xml”
Set-webservicesvirtualdirectory –Identity "$CASserver\EWS (default web site)" –internalurl “$urlpath/ews/exchange.asmx”
Set-oabvirtualdirectory –Identity "$CASserver\OAB (default web site)" –internalurl “$urlpath/oab”
Set-owavirtualdirectory –Identity "$CASserver\OWA (default web site)" –internalurl “$urlpath/owa”
Set-ecpvirtualdirectory –Identity "$CASserver\ECP (default web site)" –internalurl “$urlpath/ecp”
Set-ActiveSyncVirtualDirectory -Identity "$CASserver\Microsoft-Server-ActiveSync (default web site)" -InternalUrl "$urlpath/Microsoft-Server-ActiveSync"
#get commands to to doublecheck the config
get-AutodiscoverVirtualDirectory -Identity "$CASserver\Autodiscover (default web site)" | ft identity,internalurl
get-ClientAccessServer –Identity "$CASserver" | ft identity,AutodiscoverServiceInternalUri
get-webservicesvirtualdirectory "$CASserver\EWS (default web site)" | ft identity,internalurl
get-oabvirtualdirectory "$CASserver\OAB (default web site)" | ft identity,internalurl
get-owavirtualdirectory "$CASserver\OWA (default web site)" | ft identity,internalurl
get-ecpvirtualdirectory "$CASserver\ECP (default web site)" | ft identity,internalurl
get-ActiveSyncVirtualDirectory "$CASserver\Microsoft-Server-ActiveSync (default web site)" | ft identity,internalurl