exchange-server

How-To: Exchange Server 2007 Web Services mit einem Single Name Certificate

EXCHANGE SERVER

Die Anforderungen an eine Messaging Plattform wie Exchange Server 2007 ist längst nicht mehr auf E-Mail beschränkt. Die Kunden möchten jederzeit und von überall auf die Mailbox zugreifen. Dies wird mit Features wie Exchange Active Sync, Outlook Web Access oder auch Outlook Anywhere (RPC over HTTPS) ermöglicht.

Mit Exchange Server 2007 wurde eine Schlüsselkomponente namens “Autodiscover” eingeführt. Das Ziel dieses Services besteht darin, dass Outlook 2007 und Windows Mobile 6.1 automatisch die entsprechende Konfiguration vom Client Access Server erhalten und den Weg zur entsprechenden Mailbox oder dem Offline Adressbuch finden. Die Kommunikation findet jeweils über HTTPS, TCP Port 443, statt. By Default wird daher bei der Installation bei jedem Exchange Server, ausgenommen bei der Mailbox Role, ein “self-signed” Certificate angelegt. Dies ist natürlich weniger für eine produktive Umgebung geeignet. Der Einsatz einer öffentlichen Zertifizierungsstelle wird daher dringendst zu erwägen.

Mit Exchange Server 2007 werden verschiedene URL’s angesprochen. Es empfiehlt sich bei der Konfiguration folgende URL’s einzuplanen, für welche auch ein Zertifikat erforderlich ist:

  • mail.domain.tld (für MX-Record, SMTP, POP3, IMAP, OWA, Exchange ActiveSync)
  • autodiscover.domain.tld (Autodiscover Service)
  • srvname.internaldomain.tld (Exchange CAServer FQDN)
  • srvname (Exchange CAServer NetBIOS Name)

Damit das Management einfach und übersichtlich bleibt, wird der Einsatz eines “Subject Alternative Name” (SAN), oder auch “Unified Communications Certificates” (UCC) genannt, empfohlen. Zum aktuellen Zeitpunkt sind diese SAN Certificates noch nicht bei allen Certification Authority (CA) verfügbar. Weitere Informationen dazu im Microsoft KB 929395. Sehr guten Service bieten Digicert und GoDaddy.

In manchen Situationen kann es vorkommen, dass man kein SAN Certificate einsetzen möchte. Mit Microsoft Outlook 2007 SP1, oder entsprechendem Hotfix, ist auch die Konfiguration mit einem Single Name Certificate möglich. Ein solches bekommt man bei schon ab $30 pro Jahr. Das empfohlene Subject Alternative Name (SAN) Certificate bekommt man allerdings inzwischen schon ab $90 pro Jahr (Stand November 2008). Wichtig, die Konfiguration von Exchange Server mit einem Single Name Certificate ist durchaus komplexer und nicht für alle Services geeignet. Ob es sich nun also wirklich lohnt die paar Dollars zu sparen lassen wir mal offen stehen…

Certificate Request und Import

Am einfachsten kann ein Certificate Request mit dem Wizard von Digicert erstellt werden. Ein PowerShell cmdlet für ein Single Name Certificate für die Domain mail.server-talk.eu sieht zum Beispiel wie folgt aus: New-ExchangeCertificate -GenerateRequest -Path c:\mail_server-talk_eu.csr -KeySize 2048 -SubjectName "c=CH, s=, l=, o=Server Talk, ou=Bloggers, cn=mail.server-talk.eu" -PrivateKeyExportable $True

Dieses cmdlet muss in der Exchange Management Shell (EMS) ausgeführt werden. Nebenbei erwähnt, Unterstützung für PowerShell bietet Quest’s PowerGUI (Freeware). In den meisten Fällen wird die Bestellung durch den Certification Authority innert wenigen Stunden bearbeitet. Der offene Request kann ebenfalls in der EMS abegschlossen und das Certificate direkt aktiviert werden. Dies wird mit diesem cmdlet durchgeführt: Import-ExchangeCertificate -Path C:\ certificates\import.pfx | Enable-ExchangeCertificate -Services IIS

DNS

Da das Singele Name Certificate auf mail.server-talk.eu ausgestellt wurde, Microsoft Outlook 2007 jedoch über autodiscover.server-talk.eu den Autodiscover Service kontaktiert wird ein SSL Fehler ausgegeben. Aus diesem Grund wird die Verbindung mittels DNS auf den registrierten Namen umgeleitet. Sämtliche HOST (A)- und CNAME Records welche für den Autodiscover Service angelegt wurden sollten vorgängig bereinigt werden. Bei einem Windows DNS Server wird ein SRV-Record wie folg angelegt:

  1. Im DNS Manager den DNS-Server auswählen und die “Forward Lookup Zones” erweitern.
  2. Auf der entsprechenden Domain mittels Rechtsklick “Other New Records… ⇒ Service Location (SRV)” anwählen und mit “Create New Record…” bestätigen.
  3. Folgende Werte müssen nun eingetragen werden
    • Service: _autodiscover
    • Protocol: _tcp
    • Port Number: 443
    • Host offering this service:
  4. Mit “OK” wird der SRV-Record angelegt.

Bei einem externen DNS stehen unter Umständen weniger Felder zur Verfügung. Die Konfiguration sieht zum Beispiel bei DynDNS wie folgt aus:

  • Host: _autodiscover._tcp.server-talk.eu
  • Type: SRV
  • Data: 0 0 443 mail.server-talk.eu.

Ob nun der DNS-Record vorhanden ist und entsprechend funktioniert, kann mit nslookup getestet werden: nslookup -type=srv _autodiscover._tcp.server-talk.eu. Als Output sollte etwas in dieser Form geliefert werden:

_autodiscover._tcp.server-talk.eu SRV service location:
priority = 0
weight = 0
port = 443
svr hostname = mail.server-talk.eu

Exchange Server URL Konfiguration

Als letzer, aber durchaus einer der wichtigsten Punkte, ist die Konfiguration der Exchange Server URL’s. Für Exchange ActiveSync (EAS), Offline Address Book (OAB), Outlook Web Access (OWA) und Outlook Anywhere muss die im SSL Certificate registrierete URL als External URL und wenn auch intern über Port 443 kommuniziert werden soll, ebenfalls als Internal URL angepasst werden. Ein mögliches Konfigurations-Script wird in diesem Artikel beschrieben (comming soon).

Viele wichtige, interessante Hinweise zur Technik und Konfiguration liefert das “Exchange 2007 Autodiscover Service” White Paper von Microsoft. Weitere Unterstützung zur Konfiguration gibt es bei Franks Exchange FAQ.

Connectivity Tests

Abschliessend sollte die Konfiguration getestet werden. Besonders eignet sich dazu Microsoft’s testexchangeconnectivity.com, mit welchem sich diverse Test-Szenarien durchführen lassen.

Weitere Informationen

Exchange Server

,

About the Author

Michel Luescher ist bei Microsoft Corporation als Solution Architect im Center of Excellence (CoE) für Datacenter & Cloud Infrastructure tätig. Michel ist Speaker und Blogger rund um das Thema Microsoft Cloud und bei Microsoft zudem Subject Matter Expert (SME) für Hyper-V + System Center Virtual Machine Manager.

Comments (6)

  • brb says:

    Hi,

    habe ein Problem bei DNS “neuer eintrag”

    bei mir wird kein _Autodiscover angezeigt..

    2 Server sind im Betrieb ” eine Domäne”
    Erster Server “DNS; DHCP, AD, ROuting Ras”
    Zweiter Server “Exchange 2007″

    möchte Outlook anywhere einstellen nur ich bekomme immer Proxyfehler Code 10.

    habe nun die CA auf Exchange Server installiert und über admin pack auf den ersten Server “DC” connectet jedoch ist bei mir kein Autodiscover..

    Was mir noch auffiel ist= Beide server haben IIS installiert aber nur der von Exchange Server wird gebraucht und funktioniert auch..Auf dem Exchangeserver IIS ist autodiscover mitdabei auf dem DC scheint alles mau zu sein

    mfg

     
  • Michel says:

    Hallo

    Der “_Autodiscover” Record muss manuell im externen DNS-Server angelegt werden. Was gibt dir der nslookup retour? Ich würde allerdings keinen eigenen CA einsetzen, vor allem nicht bei einem “Single Name Certificate”…

    Wichtig! CA, IIS & co haben nur indirekt mit Autodiscover oder Outlook Anywhere zu tun. Dieser Record wird nur im DNS-Server vorgenommen. Im Exchange muss das richtige Certificate (z.B. mail.domain.com) installiert sein. Outlook Anywhere muss zudem auf diesen Namen konfiguriert werden.

    Gruss
    Michel

     
  • Bernd says:

    Was meinst du mit “externer DNS-Server” ?
    Ich habe einen 2003 SMB als DC.
    Forward Lookupzone.
    _msdcs.XXXXX.local
    XXXXX.local

    Wo ist hier mein externer DNS?

     
  • Michel says:

    Hallo Bernd, du musst den Eintrag bei dem DNS Server machen, wo du auch die MX Einträge für deine E-Mail Domain gemacht hast. Dieser kannst du in der Regel wählen, ev. ist es dein Provider, dein Hoster, oder ein Anbieter wie zum Beispiel DynDNS.org.

     
  • Teke says:

    Hallo Zusammen,

    Kleines problem mit dem Zertifikat in einer Domainen-Umgebung…

    Ich habe das bereits abgelaufene Zertifikat, durch das neue ersetzt und den alten gelöscht.
    Diesen Vorgang habe ich bereits X mal getätigt und hat jedes Mal wunderbar gefunzt.

    Nur dieses Mal irgendwie nicht so wie es sein sollte.
    Die User der Firma bekommen immernoch die Meldung des Sicherheitshinweises.
    Wenn ich das Zertifikat bei der Meldung anzeigen lasse, bekomme ich die Meldung:
    “Dieses Zertifizierungsstellen-Stammzertifikat ist nicht vertrauenswürdig. Installieren Sie das Zertifikat in den Speicher vertrauenswürdiger Stammzertifizierungsstellen, um die Vertrauensstellung zu aktivieren.”
    Gültig ist das Zertifikat jedoch!!

    Ich habe in der GPO noch einige Einstellungen geändert… siehe: http://technet.microsoft.com/de-de/library/cc754841%28WS.10%29.aspx , jedoch brachte dies auch nicht viel.

    Kann mir da ein Kollege helfen?

    Greez
    T.

     

Hinterlasse eine Antwort.