Kevin Bentlage
28/08/13, 10:32
Beste,
Wij hebben sinds een aantal maanden een Hosted Exchange 2010 omgeving draaien, dit werkt prima.
Voor het instellen van Outlook en andere devices maken we gebruik van Autodiscover, hiermee kunnen we onze klanten zelf op een gemakkelijke wijze hun account('s) laten toevoegen met enkel het e-mailadres en wachtwoord. Het enigste wat de klant hiervoor moet doen is een CNAME record "autodiscover" aanmaken met als waarde "redirect.onzedomeinnaam.nl". Deze IIS redirect zorgt ervoor dat http://autodiscover.domeinnaamvandeklant.nl wordt geredirect naar https://ex01.onzedomeinnaam.nl/autodiscover/autodiscover.xml.
Het bovenstaande is uitgevoerd a.d.v. deze tutorial en werkt prima;
http://social.technet.microsoft.com/wiki/contents/articles/5787.exchange-2010-multi-tenant-autodiscover-and-dns-configuration.aspx
Echter is er één probleem, op het moment dat de domeinnaam van de klant bijvoorbeeld is gehost op een DirectAdmin machine, staat poort 443 standaard open. Echter zit hier 9 van de 10 keer geen geldig SSL certificaat achter (simpelweg omdat de klant dit niet gebruikt of nodig heeft).
Nu is het zo dat Autodiscover een 4-tal manieren heeft om de autodiscover gegevens op te halen, deze zijn als volgt;
1. Controle of https://domeinnaam.nl/autodiscover/autodiscover.xml bestaat
2. Controle of https://autodiscover.domeinnaam.nl/autodiscover/autodiscover.xml bestaat
3. Controle of http://autodiscover.domeinnaam.nl/autodiscover/autodiscover.xml bestaat (van deze wijze maken wij dus gebruik, m.b.v. een IIS redirect)
4. Controle of een SRV record bestaat op domeinnaam.nl met daarin het juiste adres voor autodiscovery (deze wijze gebruiken we ook, maar steeds minder)
Nu worden bovenstaande stappen op exact deze volgorde uitgevoerd en dat geeft dus problemen met domeinnamen die niet zijn voorzien van een geldig SSL certificaat en waar poort 443 standaard open staat (b.v. DirectAdmin). Hierdoor geeft Outlook een error (geen geldig SSL certificaat) tijdens het opstarten en dit is uiteraard bijzonder irritant voor de gebruikers. Domeinnamen waar 443 dicht staat of waar een geldig SSL in gebruik is hebben dit probleem niet.
Om deze theorie even te bevestigen heb ik op een DirectAdmin testserver (met een testdomein zonder SSL certificaat) tijdelijk poort 443 geblokt in de firewall (CSF), de foutmelding bij Outlook is dan direct verdwenen. Zodra 443 weer werdt opengezet keerde het probleem direct terug.
Is er een manier om dit te omzeilen?
Thanks!
Wij hebben sinds een aantal maanden een Hosted Exchange 2010 omgeving draaien, dit werkt prima.
Voor het instellen van Outlook en andere devices maken we gebruik van Autodiscover, hiermee kunnen we onze klanten zelf op een gemakkelijke wijze hun account('s) laten toevoegen met enkel het e-mailadres en wachtwoord. Het enigste wat de klant hiervoor moet doen is een CNAME record "autodiscover" aanmaken met als waarde "redirect.onzedomeinnaam.nl". Deze IIS redirect zorgt ervoor dat http://autodiscover.domeinnaamvandeklant.nl wordt geredirect naar https://ex01.onzedomeinnaam.nl/autodiscover/autodiscover.xml.
Het bovenstaande is uitgevoerd a.d.v. deze tutorial en werkt prima;
http://social.technet.microsoft.com/wiki/contents/articles/5787.exchange-2010-multi-tenant-autodiscover-and-dns-configuration.aspx
Echter is er één probleem, op het moment dat de domeinnaam van de klant bijvoorbeeld is gehost op een DirectAdmin machine, staat poort 443 standaard open. Echter zit hier 9 van de 10 keer geen geldig SSL certificaat achter (simpelweg omdat de klant dit niet gebruikt of nodig heeft).
Nu is het zo dat Autodiscover een 4-tal manieren heeft om de autodiscover gegevens op te halen, deze zijn als volgt;
1. Controle of https://domeinnaam.nl/autodiscover/autodiscover.xml bestaat
2. Controle of https://autodiscover.domeinnaam.nl/autodiscover/autodiscover.xml bestaat
3. Controle of http://autodiscover.domeinnaam.nl/autodiscover/autodiscover.xml bestaat (van deze wijze maken wij dus gebruik, m.b.v. een IIS redirect)
4. Controle of een SRV record bestaat op domeinnaam.nl met daarin het juiste adres voor autodiscovery (deze wijze gebruiken we ook, maar steeds minder)
Nu worden bovenstaande stappen op exact deze volgorde uitgevoerd en dat geeft dus problemen met domeinnamen die niet zijn voorzien van een geldig SSL certificaat en waar poort 443 standaard open staat (b.v. DirectAdmin). Hierdoor geeft Outlook een error (geen geldig SSL certificaat) tijdens het opstarten en dit is uiteraard bijzonder irritant voor de gebruikers. Domeinnamen waar 443 dicht staat of waar een geldig SSL in gebruik is hebben dit probleem niet.
Om deze theorie even te bevestigen heb ik op een DirectAdmin testserver (met een testdomein zonder SSL certificaat) tijdelijk poort 443 geblokt in de firewall (CSF), de foutmelding bij Outlook is dan direct verdwenen. Zodra 443 weer werdt opengezet keerde het probleem direct terug.
Is er een manier om dit te omzeilen?
Thanks!