Hosted Exchange & SSL

[superspinnie]

Hallo,

We zijn op dit moment bezig met een project om een Hosted Exchange op te zetten op basis van Exchange 2010. We zijn al een heel eind op weg. De Exchange is goed ingericht. Echter lopen we nu tegen een aantal zaken aan.

Hierbij een aantal gegevens van onze situatie:

- Interne domeinnaam hosted exchange server: ABC.local
- SSL Certificaat aangevraagd op: hosted.DEF.nl (A record hosted.DEF.nl verwijst naar ip van de hosted exchange server)
- Extern domein (bijv. klant 1) pietjepuk.nl
- Extern domen (bijv. klant 2) jantje.nl


Hoe moeten we dan omgaan met de certificaten als er niet de mogelijkheid is om bij de provider een SRV record aan te laten maken. We krijgen het nu namelijk niet voor elkaar omdat we certificaat waarschuwingen krijgen als we een email adres willen instellen op een Outlook 2010 client van het domein pietjepuk.nl. Hij geeft aan dat de certificaatnaam niet overeen komt.

Is dit op te lossen met een multiple domain certificaat? Dit kom ik namelijk her en der tegen.

Wat doen we verkeerd? Wie kan ons tips geven?

[nielsl]

Je geeft het zelf al aan, of een multiple domain certificaat aanschaffen, of een SRV record aanmaken. Een andere mogelijkheid heb je helaas niet

[Paul]

superspinnie schreef op vrijdag 11 mei 2012 @ 15:10:
Hoe moeten we dan omgaan met de certificaten als er niet de mogelijkheid is om bij de provider een SRV record aan te laten maken.

Verhuizen, of DNS in eigen beheer nemen?

Jullie zijn DEF.nl neem ik aan? Je kunt bij de klant aanbieden hun DNS-hosting (ook) over te nemen als hun leverancier geen SRV-records aan wil maken. Bij verreweg de meeste providers kan dat overigens wel, het kost alleen af en toe wat moeite om door de 1e lijn helpdesk heen te komen als het admin-panel die optie niet geeft

[superspinnie]

dank voor de snelle reacties!

Gelukkig kunnen de meeste hosters een srv record aanmaken echter komen we er net gelijk al 1 tegen waar het niet kan.
Heeft iemand ervaring met een multiple domain certificate?

Moet je dan van te voren de domein namen opgeven en kun je er later makkelijk meer bij toevoegen?

Vast dank voor de reacties!

[Paul]

Iedere keer dat je het aanpast moet de uitgever het certificate opnieuw uitgeven (en controleren dat jij daadwerkelijk een certificate met die naam/namen aan mag vragen)

Op Wikipedia: Comparison of SSL certificates for web servers zie je een lijst (waarschijnlijk niet uitputtend) met aanbieders, het gaat dan dus vooral om de kolom 'number of domains included'.

Waarschijnlijk moet je iedere keer dat je een klant krijgt (met een hoster) die geen SRV-records ondersteunt het certificate opnieuw kopen; als je die minimaal 1x per 365 dagen erbij krijgt hoef je geen vernieuwingskosten te rekenen

[tc982]

Je gaat toch geen certificaat per domain instellen? Of SAN's per domain? Dat lijkt me onmogelijk. Ik denk dan eerder aan cname's die ze moeten laten aanmaken...

[superspinnie]

Oke, dus eigenlijk moeten wij ons huidige certificaat omzetten naar een multiple domain certificate?

Dit certificaat mag dan nog steeds als hoofddomain hosted.def.nl zijn echter komen hier dan de andere domeinen onder te hangen of hoe moeten we dit zijn? Krijgen we dan niet alsnog de foutmelding dat het certificaat niet overeenkomt met de naam?

Moet het certificaat overigens sowieso niet autodiscover.def.nl zijn wanneer er gebruik gemaakt wordt van autodiscover? anders krijgen we die foutmelding weer in outlook neem ik aan?

[superspinnie]

tc982 schreef op vrijdag 11 mei 2012 @ 16:29:
Je gaat toch geen certificaat per domain instellen? Of SAN's per domain? Dat lijkt me onmogelijk. Ik denk dan eerder aan cname's die ze moeten laten aanmaken...

als de hoster geen srv record aan kan maken heben we weinig keus denk ik?

[Paul]

De volgende namen moeten op het certificate:

- De naam die de CAS denkt te hebben voor zijn autodiscoveruri en voor de OAB/UM en Webservices virtual directories
- De naam waarop de client de autodiscover wil doen.

Welke namen zijn dat? Laten we even het e-mailadres paul @ ABC.nl nemen. Dan zijn het (in die volgorde) de volgenden adressen waar gezocht wordt:

https://abc.nl/(blabla)
https://autodiscover.abc.nl/(blabla)
http://autodiscover.abc.nl/blabla

en daarna het SRV-record. Als je dus een A-record 'autodiscover' maakt dan moet je de naam autodiscover.abc.nl op je certificate hebben

[superspinnie]

Paul schreef op vrijdag 11 mei 2012 @ 16:45:
De volgende namen moeten op het certificate:

- De naam die de CAS denkt te hebben voor zijn autodiscoveruri en voor de OAB/UM en Webservices virtual directories
- De naam waarop de client de autodiscover wil doen.

Welke namen zijn dat? Laten we even het e-mailadres paul @ ABC.nl nemen. Dan zijn het (in die volgorde) de volgenden adressen waar gezocht wordt:

https://abc.nl/(blabla)
https://autodiscover.abc.nl/(blabla)
http://autodiscover.abc.nl/blabla

en daarna het SRV-record. Als je dus een A-record 'autodiscover' maakt dan moet je de naam autodiscover.abc.nl op je certificate hebben

Duidelijk, maar als je dan paul @ abc .nl hebt en henk @ pietjepuk.nl?
Dan gaat het bij henk@pietjepuk dus mis gezien er dan geen autodiscover.pietjepuk.nl bestaat.

is dit dan op te vangen met een multiple domain certificate?

[Paul]

In mijn voorbeeld heb je al een muti-domain-certificate, tenzij je de CAS (die van bedrijf DEF is) vertelt dat 'ie autodiscover.abc.nl heet

je krijgt dus inderdaad de namen: autodiscover.def.nl, autodiscover,def.nl, autodiscover.pietjepuk.nl etc op het certificate.

[tc982]

Maar als er dan een nieuwe klant aankomt moet je elke keer opnieuw een ssl certificaat aanvragen, en per san moet je betalen. Maar ik zie niet in waarom je dat zou doen. Waarom de SRV records? Die zijn nergens voor nodig.

Als je verbind met office 365 of bpos, connecteer je toch direct met hun url. Indien je deze custom wilt, moet je nog een cname laten aanmaken.

[Paul]

1 woord: Autodiscover

En dat het met BPOS of Office 365 'wel werkt' is omdat Microsoft zelf ook een root CA is en ze dus 'gratis' dat certificate aan hun eigen servers kan hangen.

Jij en ik kunnen dat ook, geen probleem, we moeten alleen steeds een nieuw certificate aankopen (of SRV-records gebruiken. Persoonlijk had ik liever gezien dat de client die als eerste optie gebruikte ipv als laatste redmiddel want dan hoefde je geen work-arounds te verzinnen voor wildcard DNS-entries).

[Oogje]

De domeinnaam van je klant in een SSL certificaat gaat alleen maar lukken als je eigenaar bent van de domeinnaam toch? Dus dat kun je wel vergeten volgens mij.

[Dysmael]

Bovendien wil je niet een hele waslijst van domeinen in je certificaat zodat iedereen kan zien voor wie jij allemaal host.
Het is wellicht het handigst om een wildcard certifcaat te gebruiken. Dan laat je iedereen verbinden naar hundomein.jouwdomein.nl. Of zelf certificaten uitdelen. Nadeel daarvan is dat je extra handelingen moet verrichten op de client (root CA cert toevoegen)

[tc982]

Ik heb al heel wat Office 365 migraties gedaan, en ze gebruiken gewoon het volgende voor exchange online :

- MX record : bedrijfsnaam.mail.eo.outlook.com
- CNAME : autodiscover.bedrijf.nl naar autodiscover.outlook.com

Er worden geen srv records aangemaakt, enkel voor Lync. En meer heb je toch niet nodig? Vanwaar al die certificaten komen weet ik niet.

[superspinnie]

tc982 schreef op zondag 13 mei 2012 @ 15:17:
Ik heb al heel wat Office 365 migraties gedaan, en ze gebruiken gewoon het volgende voor exchange online :

- MX record : bedrijfsnaam.mail.eo.outlook.com
- CNAME : autodiscover.bedrijf.nl naar autodiscover.outlook.com

Er worden geen srv records aangemaakt, enkel voor Lync. En meer heb je toch niet nodig? Vanwaar al die certificaten komen weet ik niet.

In jou voorbeeld maak je gebruik van Office 365.
Dit doen wij niet, wij zetten een eigen hosted exchange server op.
Volgens mij gaat jou voorbeeld dan niet op toch?

[Oogje]

Volgens mij wel...... autodiscover,klant.nl laten verwijzen naar autodiscover.def.nl

Maar dan moet je eigen cert wel de autodiscover bevatten.

[tc982]

superspinnie schreef op maandag 14 mei 2012 @ 09:09:
[...]


In jou voorbeeld maak je gebruik van Office 365.
Dit doen wij niet, wij zetten een eigen hosted exchange server op.
Volgens mij gaat jou voorbeeld dan niet op toch?

Waarom niet, office 365 is gewoon een hosted exchange enviremont.

[superspinnie]

Oogje schreef op maandag 14 mei 2012 @ 09:51:
Volgens mij wel...... autodiscover,klant.nl laten verwijzen naar autodiscover.def.nl

Maar dan moet je eigen cert wel de autodiscover bevatten.

Oke, maar hoe laat je een autodiscover.klant.nl verwijzen naar autodiscover.def.nl ?

[Verwijderd]

superspinnie schreef op maandag 14 mei 2012 @ 13:29:
[...]


Oke, maar hoe laat je een autodiscover.klant.nl verwijzen naar autodiscover.def.nl ?

CNAME maken; autodiscover verwijzende naar autodiscover.def.nl

[Paul]

Maar dan moet de webserver van autodiscover.def.nl nog steeds een certificate hebben (of een subject alternate name) op autodiscover.klant.nl, een website verwacht nog steeds de naam die het aanvroeg en of dat IP-adres nu via een CNAME of een A-record komt maakt niet uit afaik.

Anders zet ik google.nl hier op het werk wel met een CNAME naar mijn eigen reverse proxy, lekker alles afvangen...

[superspinnie]

Paul schreef op maandag 14 mei 2012 @ 14:28:
Maar dan moet de webserver van autodiscover.def.nl nog steeds een certificate hebben (of een subject alternate name) op autodiscover.klant.nl, een website verwacht nog steeds de naam die het aanvroeg en of dat IP-adres nu via een CNAME of een A-record komt maakt niet uit afaik.

Anders zet ik google.nl hier op het werk wel met een CNAME naar mijn eigen reverse proxy, lekker alles afvangen...

Dat is dus ook wat ik dacht. Maar dit betekend dan toch dat je voor elke klant een nieuw certificaat aan moet maken of een multiple domain certificate moet gaan gebruiken waar voor elke klant autodiscover.klant.nl in voorkomt?

[Paul]

Hmm, ik zit even te spelen met de autodiscover van Office 365, daar passen ze een ander trucje toe:

Autodiscover probeert, als HTTPS niet werkt, ook HTTP...

Wat doen ze dus: autodiscover.klant.nl CNAME autodiscover.outlook.com, en op die URL / dat IP draait helemaal geen HTTPS!

http://autodiscover.outlook.com (zonder S!) redirect naar https://autodiscover-s.outlook.com en vanaf daar is het allemaal (nu ja, qua autodiscover) met 1 certificate geregeld...

[tc982]

Paul schreef op maandag 14 mei 2012 @ 14:28:
Maar dan moet de webserver van autodiscover.def.nl nog steeds een certificate hebben (of een subject alternate name) op autodiscover.klant.nl, een website verwacht nog steeds de naam die het aanvroeg en of dat IP-adres nu via een CNAME of een A-record komt maakt niet uit afaik.

Anders zet ik google.nl hier op het werk wel met een CNAME naar mijn eigen reverse proxy, lekker alles afvangen...

Neen, dat is niet nodig, een cname is een redirect, er word eerst een dns request gedaan naar autodiscover.domain.nl, vervolgens word deze door de cname veranderd naar autodiscover.hostedexchange.nl. Outlook zal dan naar dat domain een rpc over https request starten.

Heb je überhaut al eens een hosted exchange omgeving bekeken? Want er komt wel wat meer bij kijken dan dat alleen al.

[superspinnie]

tc982 schreef op maandag 14 mei 2012 @ 15:26:
[...]


Neen, dat is niet nodig, een cname is een redirect, er word eerst een dns request gedaan naar autodiscover.domain.nl, vervolgens word deze door de cname veranderd naar autodiscover.hostedexchange.nl. Outlook zal dan naar dat domain een rpc over https request starten.

Heb je überhaut al eens een hosted exchange omgeving bekeken? Want er komt wel wat meer bij kijken dan dat alleen al.

Oke, ja het hosted gedeelte hebben we meerdere malen mee te maken gehad. Deze hebben wij ook opgezet en functioneert ook prima! het enige waar we in "vast" lopen zijn de certificaten. We hebben net een certificaat aangevraagd "autodiscover.def.nl" bij Godaddy.Wanneer we bij onze klanten nu dus een Cname aanmaken autodiscover en deze laten verwijzen naar autodiscover.def.nl moet het goed gaan?

[Paul]

tc982 schreef op maandag 14 mei 2012 @ 15:26:
Neen, dat is niet nodig, een cname is een redirect, er word eerst een dns request gedaan naar autodiscover.domain.nl, vervolgens word deze door de cname veranderd naar autodiscover.hostedexchange.nl. Outlook zal dan naar dat domain een rpc over https request starten.

Misschien dat Outlook dat doet, je browser doet het in ieder geval zeer zeker niet.

Er wordt een _DNS_-request gedaan, het HTTPS-request gaat wel degelijk naar de originele naam (en naar het ip dat gevonden wordt, of dat via-via dmv een CNAME, een A of een AAAA gaat maakt niet uit) en geeft dus een error als er een certificate met een andere naam dan het origineel (bijvoorbeeld de CNAME) gegeven wordt.

En nee, ik heb nooit echt gekeken naar het opzetten van een hosted Exchange, is dat nodig om te snappen hoe HTTPS-requests werken of hoe Outlook Autodiscover werkt (in ieder geval op een niet-hosted Exchange) ? Want het is wel interessante materie. Alleen al hoe je meerdere gebruikers compleet van elkaar gescheiden weet te krijgen lijkt me al flink lastig; normaal zit iedereen in hetzelfde domein en in dezelfde GAL.

[ Voor 14% gewijzigd door Paul op 14-05-2012 15:39 ]

[begintmeta]

Paul schreef op maandag 14 mei 2012 @ 15:34:
... HTTPS-request gaat wel degelijk naar de originele naam (en naar het ip dat gevonden wordt, of dat via-via dmv een CNAME, een A of een AAAA gaat maakt niet uit) en geeft dus een error als er een certificate met een andere naam dan het origineel (bijvoorbeeld de CNAME) gegeven wordt. ...

Een workaround hiervoor is toch SNI?

[Paul]

Dan heb je nog steeds een cert nodig voor autodiscover.klant.nl maar dan hoeft het tenminste geen SAN-certificate (of wildcard, of multidomain of whatever) te zijn.

Echter, (van de Wikipedia-pagina, dat wel): "As of 2012 there are still many users of browsers that do not support SNI." Geen idee of ze Outlook 2003 en 2007 geüpdatet hebben

[superspinnie]

Met een cname gaat het niet werken. Net getest en je krijgt alsnog de melding in outlook 2010 dat het certificaat niet overeen komt. Er wordt dus nog steeds gezocht naar autodiscover.klant.nl

[begintmeta]

Ik geloof dat dar niet zoveel aan te doen is (behalve door MS natuurlijk)

[Paul]

1. Maak een HTTP-only website (op een IP waar dus geen SSL-site draait) met daarin de host headers / bindings voor alle klanten (of desnoods is het de default website)
2. Laat deze redirecten naar https://autodiscover.def.nl (met een 302)
3. ...
4. Profit!

Zo doet Office 365 het kwam ik vandaag achter

[superspinnie]

Paul schreef op maandag 14 mei 2012 @ 16:16:

1. Maak een HTTP-only website (op een IP waar dus geen SSL-site draait) met daarin de host headers / bindings voor alle klanten (of desnoods is het de default website)
2. Laat deze redirecten naar https://autodiscover.def.nl (met een 302)
3. ...
4. Profit!

Zo doet Office 365 het kwam ik vandaag achter

Kun je ons dit misschien iets duidelijker uitleggen? Ik ben het overigens meer tegengekomen, dit is volgens mij de http redirect oplossing.

Wanneer je de exchange connectivity test uitvoert op internet test hij als laatste stap volgens mij ook of er een http redirect aanwezig is.

[superspinnie]

We gaan er morgen mee verder. Volgens mij moet het met de http redirect te realiseren zijn.

Zie:

http://technet.microsoft.com/en-us/library/ff923256.aspx

http://social.technet.mic...nd-dns-configuration.aspx

[superspinnie]

de http redirect gaat nu goed wanneer ik hem test via de exchangeconnectivitytest maar blijf alsnog de melding krijgen dat het certificaat niet overeen komt. Iemand ideeen?

[Dysmael]

Paul schreef op maandag 14 mei 2012 @ 15:34:
[...]
Alleen al hoe je meerdere gebruikers compleet van elkaar gescheiden weet te krijgen lijkt me al flink lastig; normaal zit iedereen in hetzelfde domein en in dezelfde GAL.

Beide geen probleem. Aparte GAL maken kan gewoon en domeinen hou je gescheiden met bv een one-way trust en linked mailboxes. Zelf zo'n Exchange omgeving afgelopen weekend nog in een VM opgezet met twee domeinen die volledig gescheiden werken van elkaar.

Edit: Je kan bv ook aparte UPN's maken. En in Exchange 2010 SP2 zit aardig wat verschil t.a.v. de /hosted optie van Exchange 2010 (pre)-SP1

[ Voor 11% gewijzigd door Dysmael op 14-05-2012 21:30 ]

[Jazzy]

Ik ben wel een beetje verbaasd dat je ervaring hebt met hosted Exchange maar vast loopt met iets bassaals als Autodiscover en certificaten. Wat doe je eigenlijk, /hosting of de on-prem installatie van Exchange 2010?

[Paul]

superspinnie schreef op maandag 14 mei 2012 @ 20:31:
de http redirect gaat nu goed wanneer ik hem test via de exchangeconnectivitytest maar blijf alsnog de melding krijgen dat het certificaat niet overeen komt. Iemand ideeen?

Wat zegt die site en wat zegt Outlook? Het is mij nog niet gelukt beiden iets verschillends te laten zeggen (enkel dat die site veel meer info geeft).

RolfLobker schreef op maandag 14 mei 2012 @ 21:28:
Beide geen probleem. Aparte GAL maken kan gewoon en domeinen hou je gescheiden met bv een one-way trust en linked mailboxes. Zelf zo'n Exchange omgeving afgelopen weekend nog in een VM opgezet met twee domeinen die volledig gescheiden werken van elkaar.

Ah, het kost je dus inderdaad per klant minimaal 1x SPLA Windows Server 2008 (en liever nog 2 om de DC's redundant te hebben)?

[Dysmael]

Paul schreef op maandag 14 mei 2012 @ 22:30:
[...]
Wat zegt die site en wat zegt Outlook? Het is mij nog niet gelukt beiden iets verschillends te laten zeggen (enkel dat die site veel meer info geeft).
[...]
Ah, het kost je dus inderdaad per klant minimaal 1x SPLA Windows Server 2008 (en liever nog 2 om de DC's redundant te hebben)?

Je hebt gelijk. Biedt je alleen Exchange aan dan is een aparte DC per klant niet handig. Je hoeft overigens niet een SPLA per gebruiker te hebben.Per CPU SPLA Windows 2008R2 Enterprise is handiger. Het hoeft ook niet een apart domein per organisatie te zijn; je kan ook een forest met meerdere domeinen gebruiken zoals [e-mail].
Je kan alles binnen het Exchange domein gebruiken. On premise Exchange 2010 SP2 met afzonderlijke OU's per organisatie en een UPN per organisatie is volgens mij beter.

Jazzy schreef op maandag 14 mei 2012 @ 21:43:
Ik ben wel een beetje verbaasd dat je ervaring hebt met hosted Exchange maar vast loopt met iets bassaals als Autodiscover en certificaten. Wat doe je eigenlijk, /hosting of de on-prem installatie van Exchange 2010?

My thoughts exactly.

[ Voor 15% gewijzigd door Dysmael op 15-05-2012 07:48 ]

[superspinnie]

RolfLobker schreef op maandag 14 mei 2012 @ 21:28:
[...]


Beide geen probleem. Aparte GAL maken kan gewoon en domeinen hou je gescheiden met bv een one-way trust en linked mailboxes. Zelf zo'n Exchange omgeving afgelopen weekend nog in een VM opgezet met twee domeinen die volledig gescheiden werken van elkaar.

Edit: Je kan bv ook aparte UPN's maken. En in Exchange 2010 SP2 zit aardig wat verschil t.a.v. de /hosted optie van Exchange 2010 (pre)-SP1

Die doe je door de /hosting parameter te gebruiken. Zoals eerder aangegeven werkt de exchange goed maar de certificaten niet.

[superspinnie]

Jazzy schreef op maandag 14 mei 2012 @ 21:43:
Ik ben wel een beetje verbaasd dat je ervaring hebt met hosted Exchange maar vast loopt met iets bassaals als Autodiscover en certificaten. Wat doe je eigenlijk, /hosting of de on-prem installatie van Exchange 2010?

Hoezo? certificaten en autodiscover is een een onderdeel op zich. De /hosting paramater gebruikt gezien je het anders niet goed gescheiden kunt houden.

[Paul]

RolfLobker schreef op dinsdag 15 mei 2012 @ 07:47:
Je hebt gelijk. Biedt je alleen Exchange aan dan is een aparte DC per klant niet handig. Je hoeft overigens niet een SPLA per gebruiker te hebben. Per CPU SPLA Windows 2008R2 Enterprise is handiger.

Ik ben even roestig of Windows Server ook SAL's heeft of enkel CPU-licenties, wij doen vooral hosting en dan zijn 7 miljard SAL's niet handig; Windows Server doen we altijd per CPU

Het hoeft ook niet een apart domein per organisatie te zijn; je kan ook een forest met meerdere domeinen gebruiken zoals [e-mail].

Een apart domein hoeft niet, je kunt ook meerdere domeinen gebruiken? Ik denk dat ik iets mis

Je kan alles binnen het Exchange domein gebruiken. On premise Exchange 2010 SP2 met afzonderlijke OU's per organisatie en een UPN per organisatie is volgens mij beter.

Meerdere organisaties binnen één Exchange-bak die bij je op kantoor staat? Bij een bedrijvenverzamelgebouw kan ik me daar iets bij voorstellen maar anders ben ik bang dat ik je 'on premise' niet snap

[superspinnie]

Paul schreef op dinsdag 15 mei 2012 @ 09:02:
[...]
Ik ben even roestig of Windows Server ook SAL's heeft of enkel CPU-licenties, wij doen vooral hosting en dan zijn 7 miljard SAL's niet handig; Windows Server doen we altijd per CPU

[...]
Een apart domein hoeft niet, je kunt ook meerdere domeinen gebruiken? Ik denk dat ik iets mis
[...]
Meerdere organisaties binnen één Exchange-bak die bij je op kantoor staat? Bij een bedrijvenverzamelgebouw kan ik me daar iets bij voorstellen maar anders ben ik bang dat ik je 'on premise' niet snap

Nee, hiervoor is toch juist de /hosting parameter voor uitgevonden?

[superspinnie]

Paul schreef op maandag 14 mei 2012 @ 22:30:
[...]
Wat zegt die site en wat zegt Outlook? Het is mij nog niet gelukt beiden iets verschillends te laten zeggen (enkel dat die site veel meer info geeft).
[...]
Ah, het kost je dus inderdaad per klant minimaal 1x SPLA Windows Server 2008 (en liever nog 2 om de DC's redundant te hebben)?

Dit krijg ik bij de test (succesvol)

Attempting to contact the Autodiscover service using the HTTP redirect method.
The Autodiscover service was successfully contacted using the HTTP redirect method.

Test Steps

Attempting to resolve the host name autodiscover.beentjesgravenland.nl in DNS.
The host name resolved successfully.

Additional Details
IP addresses returned: 94.247.1.160
Testing TCP port 80 on host autodiscover.beentjesgravenland.nl to ensure it's listening and open.
The port was opened successfully.
ExRCA is checking the host autodiscover.beentjesgravenland.nl for an HTTP redirect to the Autodiscover service.
The redirect (HTTP 301/302) response was received successfully.

Additional Details
Redirect URL: https://autodiscover.bvd-...discover/autodiscover.xml
Attempting to test potential Autodiscover URL https://autodiscover.bvd-...discover/autodiscover.xml
Testing of the Autodiscover URL was successful.

Test Steps

Attempting to resolve the host name autodiscover.bvd-zwolle.nl in DNS.
The host name resolved successfully.

Additional Details
IP addresses returned: 94.247.1.160
Testing TCP port 443 on host autodiscover.bvd-zwolle.nl to ensure it's listening and open.
The port was opened successfully.
Testing the SSL certificate to make sure it's valid.
The certificate passed all validation requirements.

Test Steps

ExRCA is attempting to obtain the SSL certificate from remote server autodiscover.bvd-zwolle.nl on port 443.
ExRCA successfully obtained the remote SSL certificate.

Additional Details
Remote Certificate Subject: CN=autodiscover.bvd-zwolle.nl, OU=Domain Control Validated, O=autodiscover.bvd-zwolle.nl, Issuer: SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US.
Validating the certificate name.
The certificate name was validated successfully.

Additional Details
Host name autodiscover.bvd-zwolle.nl was found in the Certificate Subject Common name.
Certificate trust is being validated.
The certificate is trusted and all certificates are present in the chain.

Test Steps

ExRCA is attempting to build certificate chains for certificate CN=autodiscover.bvd-zwolle.nl, OU=Domain Control Validated, O=autodiscover.bvd-zwolle.nl.
One or more certificate chains were constructed successfully.

Additional Details
A total of 1 chains were built. The highest quality chain ends in root certificate OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US.
Analyzing the certificate chains for compatibility problems with versions of Windows.
Potential compatibility problems were identified with some versions of Windows.

Additional Details
ExRCA can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.
Testing the certificate date to confirm the certificate is valid.
Date validation passed. The certificate hasn't expired.

Additional Details
The certificate is valid. NotBefore = 5/14/2012 1:41:18 PM, NotAfter = 5/14/2013 1:41:18 PM
Checking the IIS configuration for client certificate authentication.
Client certificate authentication wasn't detected.

Additional Details
Accept/Require Client Certificates isn't configured.
Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
ExRCA successfully retrieved Autodiscover settings by sending an Autodiscover POST.

Test Steps

ExRCA is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.bvd-...discover/autodiscover.xml for user [e-mail].
The Autodiscover XML response was successfully retrieved.

Additional Details
Autodiscover Account Settings
XML response:
<?xml version="1.0"?>
<Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>Bert</DisplayName>
<LegacyDN>/o=HostedExchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Bert</LegacyDN>
<DeploymentId>b79bcd84-66ee-4839-b677-7cd3f84a06c8</DeploymentId>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol>
<Type>EXCH</Type>
<Server>EXCHSERV01.BVD.LOCAL</Server>
<ServerDN>/o=HostedExchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCHSERV01</ServerDN>
<ServerVersion>738180DA</ServerVersion>
<MdbDN>/o=HostedExchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCHSERV01/cn=Microsoft Private MDB</MdbDN>
<ASUrl>https://autodiscover.bvd-zwolle.nl/ews/exchange.asmx</ASUrl>
<OOFUrl>https://autodiscover.bvd-zwolle.nl/ews/exchange.asmx</OOFUrl>
<OABUrl>https://autodiscover.bvd-zwolle.nl/oab/8beba5ea-fd60-4dd6-b3eb-fccb4d1d17a1/</OABUrl>
<UMUrl>https://autodiscover.bvd-zwolle.nl/ews/UM2007Legacy.asmx</UMUrl>
<Port>0</Port>
<DirectoryPort>0</DirectoryPort>
<ReferralPort>0</ReferralPort>
<AD>EXCHSERV01.BVD.LOCAL</AD>
<EwsUrl>https://autodiscover.bvd-zwolle.nl/ews/exchange.asmx</EwsUrl>
<EcpUrl>https://autodiscover.bvd-zwolle.nl/EWS/Exchange.asmx/</EcpUrl>
<EcpUrl-um>?p=customize/voicemail.aspx&exsvurl=1</EcpUrl-um>
<EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&exsvurl=1</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt>
<EcpUrl-ret>?p=organize/retentionpolicytags.slab&exsvurl=1</EcpUrl-ret>
<EcpUrl-sms>?p=sms/textmessaging.slab&exsvurl=1</EcpUrl-sms>
</Protocol>
<Protocol>
<Type>EXPR</Type>
<Server>hosted.bevede.nl</Server>
<ASUrl>https://autodiscover.bvd-zwolle.nl/ews/exchange.asmx</ASUrl>
<OOFUrl>https://autodiscover.bvd-zwolle.nl/ews/exchange.asmx</OOFUrl>
<OABUrl>https://autodiscover.bvd-zwolle.nl/oab/8beba5ea-fd60-4dd6-b3eb-fccb4d1d17a1/</OABUrl>
<UMUrl>https://autodiscover.bvd-zwolle.nl/ews/UM2007Legacy.asmx</UMUrl>
<Port>0</Port>
<DirectoryPort>0</DirectoryPort>
<ReferralPort>0</ReferralPort>
<SSL>On</SSL>
<AuthPackage>Ntlm</AuthPackage>
<EwsUrl>https://autodiscover.bvd-zwolle.nl/ews/exchange.asmx</EwsUrl>
<EcpUrl>https://autodiscover.bvd-zwolle.nl/EWS/Exchange.asmx/</EcpUrl>
<EcpUrl-um>?p=customize/voicemail.aspx&exsvurl=1</EcpUrl-um>
<EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&exsvurl=1</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt>
<EcpUrl-ret>?p=organize/retentionpolicytags.slab&exsvurl=1</EcpUrl-ret>
<EcpUrl-sms>?p=sms/textmessaging.slab&exsvurl=1</EcpUrl-sms>
</Protocol>
<Protocol>
<Type>WEB</Type>
<Port>0</Port>
<DirectoryPort>0</DirectoryPort>
<ReferralPort>0</ReferralPort>
<Internal>
<OWAUrl AuthenticationMethod="Basic, Fba">https://autodiscover.bvd-zwolle.nl/owa/</OWAUrl>
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://autodiscover.bvd-zwolle.nl/ews/exchange.asmx</ASUrl>
</Protocol>
</Internal>
<External>
<OWAUrl AuthenticationMethod="Fba">https://autodiscover.bvd-zwolle.nl/owa/</OWAUrl>
<Protocol>
<Type>EXPR</Type>
<ASUrl>https://autodiscover.bvd-zwolle.nl/ews/exchange.asmx</ASUrl>
</Protocol>
</External>
</Protocol>
</Account>
</Response>
</Autodiscover>


Dit krijg ik in outlook 2010:

[Paul]

En welk certificaat krijg je als je op 'Certificaat weergeven...' klikt?

Zo te zien draaien zowel autodiscover.beentjesgravenland.nl als autodiscover.bvd-zwolle.nl op hetzelfde IP-adres. Ik weet niet of Outlook SNI ondersteunt maar de 2e link die je gisteren om half 5 doorstuurde zei al dat je 2 ip-adressen moet hebben

[superspinnie]

Paul schreef op dinsdag 15 mei 2012 @ 09:30:
En welk certificaat krijg je als je op 'Certificaat weergeven...' klikt?

Zo te zien draaien zowel autodiscover.beentjesgravenland.nl als autodiscover.bvd-zwolle.nl op hetzelfde IP-adres. Ik weet niet of Outlook SNI ondersteunt maar de 2e link die je gisteren om half 5 doorstuurde zei al dat je 2 ip-adressen moet hebben

Certificaat weergeven is autodiscover.bvd-zwolle.nl (dit was is ons voorbeeld DEF.nl) dit is het geinstalleerde certificaat en is dus ook goed.

In iis heb ik een tweede ip adres toegevoegd op de netwerkkaart en deze alleen op poort 80 laten luisteren en een redeirect ingesteld naar de https://autodiscover.bvd-...discover/autodiscover.xml

[Paul]

Dan moet je nu de DNS van autodiscover.beentjesgravenland.nl nog aanpassen, nu is dat een CNAME naar autodiscover.bvd-zwolle.nl, dat moet een A of een CNAME worden naar het IP waarop GEEN SSL-website te vinden is

[superspinnie]

Paul schreef op dinsdag 15 mei 2012 @ 09:49:
Dan moet je nu de DNS van autodiscover.beentjesgravenland.nl nog aanpassen, nu is dat een CNAME naar autodiscover.bvd-zwolle.nl, dat moet een A of een CNAME worden naar het IP waarop GEEN SSL-website te vinden is

Dank voor de snelle reacties!

Ik dacht dat ik dat voor elkaar gemaakt had.

Heb het namelijk zo:

netwerkkaart met 2 adressen

10.0.0.8
10.0.0.9 (extra toegevoegd)

de http verbindingen komen binnen op 10.0.0.8, deze redirect door naar de https welke binnenkomen op 10.0.0.9.

[Paul]

Het gaat om externe IP-adressen, als Outlook naar 94.247.1.160 connect treft het daar zowel op poort 80 als op poort 443 een webserver aan.

Dat deze achter NAT zitten en beiden naar een ander intern IP gaan maakt niet uit, HTTPS op de originele (niet-redirected) naam levert een site + verkeerd certificaat op

[superspinnie]

Paul schreef op dinsdag 15 mei 2012 @ 09:57:
Het gaat om externe IP-adressen, als Outlook naar 94.247.1.160 connect treft het daar zowel op poort 80 als op poort 443 een webserver aan.

Dat deze achter NAT zitten en beiden naar een ander intern IP gaan maakt niet uit, HTTPS op de originele (niet-redirected) naam levert een site + verkeerd certificaat op

Ik denk dat ik begrijp wat je bedoeld.

Voordat de redirect wordt doorgevoerd vind hij al certificaat. In principe moeten we hem dus op een andere webserver binnen laten komen waar geen certificaat op draait. Deze moet dan redirecten naar de hosted exchange server waar het certificaat autodiscover.bvd-zwolle.nl op draait?


(hoewel ik het idee had dat in het artikel van microsoft stond dat het kon door een tweede ip adres op je netwerkkaart te zetten)

[Paul]

In veruit de meeste hosted omgevingen hebben servers dan ook externe IP-adressen Overdreven gesteld: Op kantoor op je SLA-loze ADSL-lijntje een machine door je Experiabox NATten is gewoon een pruts-oplossing

En zelfs als je colocated bij Redhosting zit dan is het maar de vraag of NAT de beste oplossing is; het zorgt vaak voor meer problemen dan dat het oplost; beter zet je gewoon een echte router/firewall/filtering bridge neer. Maar goed, ik weet niet waarom jullie bepaalde keuze gemaakt hebben dus zal ik ze niet aanvallen

En ja, uit veiligheidsoverwegingen wordt eerst HTTPS geprobeerd en daarna pas HTTP

[superspinnie]

Paul schreef op dinsdag 15 mei 2012 @ 10:08:
In veruit de meeste hosted omgevingen hebben servers dan ook externe IP-adressen Overdreven gesteld: Op kantoor op je SLA-loze ADSL-lijntje een machine door je Experiabox NATten is gewoon een pruts-oplossing

En zelfs als je colocated bij Redhosting zit dan is het maar de vraag of NAT de beste oplossing is; het zorgt vaak voor meer problemen dan dat het oplost; beter zet je gewoon een echte router/firewall/filtering bridge neer. Maar goed, ik weet niet waarom jullie bepaalde keuze gemaakt hebben dus zal ik ze niet aanvallen

En ja, uit veiligheidsoverwegingen wordt eerst HTTPS geprobeerd en daarna pas HTTP

Duidelijk! wij hebben hier in onze test omgeving 5 externe ip adressen dus we gaan er een tweede netwerkkaart inbouwen. (dit is allemaal nog een test omgeving, mocht alles goed gaan werken dan komt deze uiteraard in een datacenter te hangen)

We gaan er gelijk mee bezig! bedankt tot zover en we houden je op de hoogte!

[Paul]

2e netwerkkaart is vaak niet nodig 5-ipadressen, klinkt als een /29 -network -broadcast -router?

Vaak kun je in je router meerdere (externe) ip-adressen aangeven; je moet dan bij de port forwards opgeven welk extern IP er bij de forward hoort

[superspinnie]

Paul schreef op dinsdag 15 mei 2012 @ 10:22:
2e netwerkkaart is vaak niet nodig 5-ipadressen, klinkt als een /29 -network -broadcast -router?

Vaak kun je in je router meerdere (externe) ip-adressen aangeven; je moet dan bij de port forwards opgeven welk extern IP er bij de forward hoort

Dat klopt echter hebben we deze in onze testomgeving nu niet beschikbaar.

We lossen het alsvolgt op.

twee a records:

autodiscover.bvd-zwolle.nl --> extern ip adres 1 ---> https
redirect.bvd-zwolle.nl --> extern ip adres 2 --> http --. redirect naar https://autodiscover.bvd-...discover/autodiscover.xml

voor de klanten maken we cname aan autodiscover.klantnaam.nl met inhoud redirect.bvd-zwolle.nl

Volgens mij moet dat ook werken toch?

[Paul]

[superspinnie]

Paul schreef op dinsdag 15 mei 2012 @ 10:29:

We komen langzaam verder

Autodiscover wordt nu gevonden, we krijgen echter nog wel de melding dat het postvak niet beschikbaar is, controleer of exchange online is. Hier gaan we nu dus de oorzaak/oplossing van zoeken.

[superspinnie]

Ik verwacht dat de urls voor owa, rpc, webservices e.d. op autodiscover.bvd-zwolle.nl moeten blivjens taan en niet verwijzen naar redirect.bvd-zwolle.nl?

[Paul]

Ja, op dat adres en met dat certificate draaien de webservices dus daar moeten ze heen wijzen

[superspinnie]

Paul schreef op dinsdag 15 mei 2012 @ 13:34:
Ja, op dat adres en met dat certificate draaien de webservices dus daar moeten ze heen wijzen

Paul, Bedankt voor alle moeite!!

Tot nu toe werkt het probleemloos op outlook 2007 en outlook 2010.

Hij vindt alle url's uit zichzelf via autodiscover, super!

Komende dagen gaan we verschillende situaties testen

[Turdie]

Waarom gebruik je niet gewoon een wildcard certificaat en laat je iedereen connecten naar hetzelfde adres?

Daarmee los je meteen op dat je in de toekomst voor iedere klant een certificaat moet installeren op je omgeving.

[ Voor 8% gewijzigd door Turdie op 15-05-2012 13:57 ]

[superspinnie]

shadowman12 schreef op dinsdag 15 mei 2012 @ 13:56:
Waarom gebruik je niet gewoon een wildcard certificaat en laat je iedereen connecten naar hetzelfde adres?

Daarmee los je meteen op dat je in de toekomst voor iedere klant een certificaat moet installeren op je omgeving.

Dat werkt niet, dan moet je voordat je het certificaat aanmaakt al weten welke domeinen je allemaal gaat hosten.
Daarnaast is zo een certificaat duurder.
We hebben nu een single domain certificaat en de redirect werkt perfect.

Nu hoeven we juist niet voor elke klant een nieuw certificaat aan te maken, de klant hoeft enkel en cname record aan te maken in de dns welke verwijst naar onze redirect.

[Paul]

Iedere cliënt connect nu ook naar hetzelfde adres; het probleem was die cliënten daarvan zien te overtuigen

De enige soort wildcard die hiertegen bestand zou zijn is "*" als je zowel autodiscover.abc.nl als autodiscover.def.nl zou willen matchen. Hierdoor matcht ook automatisch www.google.nl, www.fbi.gov, www.facebook.com etc.

Er is echt geen enkele certificeringinstantie (op mogelijk Diginotar na ) die je dat certificaat gaat geven

[Dysmael]

Paul schreef op dinsdag 15 mei 2012 @ 09:02:
[...]
Ik ben even roestig of Windows Server ook SAL's heeft of enkel CPU-licenties, wij doen vooral hosting en dan zijn 7 miljard SAL's niet handig; Windows Server doen we altijd per CPU

Er zijn SAL's voor Windows Server maar zoals je zelf al aangeeft is in de meeste gevallen een per CPU licentie handiger.

[...]
Een apart domein hoeft niet, je kunt ook meerdere domeinen gebruiken? Ik denk dat ik iets mis

Ik denk het ook. Denk je misschien aan accepted e-mail domains? Daar had ik het namelijk niet over. Ik doelde op een Active Directory domein. Specifieker: Het 'hosted Exchange'-domein en het domein van de klant.

[...]
Meerdere organisaties binnen één Exchange-bak die bij je op kantoor staat? Bij een bedrijvenverzamelgebouw kan ik me daar iets bij voorstellen maar anders ben ik bang dat ik je 'on premise' niet snap

Ik doelde op een On Premise installatie. Niet daadwerkelijk 'On Premise' plaatsen. Ik zie een paar keer voorbij komen dat de /hosting parameter wordt aangehaald. Sinds de komst van 2010 SP2 is /hosting achterhaald:

http://blogs.technet.com/...e-pack-2-and-hosting.aspx
Belangrijk leesvoer: Multi-Tenancy and Hosting Guidance for Exchange Server 2010 SP2

[Paul]

RolfLobker schreef op dinsdag 15 mei 2012 @ 20:28:
[...]
Ik denk het ook. Denk je misschien aan accepted e-mail domains? Daar had ik het namelijk niet over. Ik doelde op een Active Directory domein. Specifieker: Het 'hosted Exchange'-domein en het domein van de klant.

Ik ook Ik denk dat je met jouw 2e 'domeinen' in het stuk dat ik quote een aparte UPN bedoelt?

Ik doelde op een On Premise installatie. Niet daadwerkelijk 'On Premise' plaatsen.

Ah, zit daar verschil in. Ik kan me uit mijn 70-662 geen onderscheid tussen hosting / on-premise herinneren dus mijn associatie met 'on-premises' was de fysieke locatie

[Jazzy]

Paul schreef op woensdag 16 mei 2012 @ 06:22:
Ah, zit daar verschil in. Ik kan me uit mijn 70-662 geen onderscheid tussen hosting / on-premise herinneren dus mijn associatie met 'on-premises' was de fysieke locatie

De verwarring zit hem inderdaad in de verschillende termen. Met /hosting wordt een installatie van Exchange 2010 met de /hosting optie bedoeld. Dat betekent: geen EMC, UM, Edge Transport, child domains, IRM, ADFS en Publioc Folders. Wanneer je dan hosting doet met de 'gewone' versie van Exchange, wat ondersteund wordt sinds SP2, dan noemt men dat hosting met de on-premises versie van Exchange.

Hosting is trouwens geen onderdeel van de MCITP en MCTS certificeringen van Exchange 2010.

[ Voor 6% gewijzigd door Jazzy op 16-05-2012 09:07 ]