Fragen zu Exchange 2013 Zertifikat

[=BT=Viper 11]

Ich plage mich mit diesem Problem schon einige Tage herum, konnte aber keine vernünftige Lösung finden.

 

Aber erstmal zum System: Server 2008 R2 mit Exchange 2013 SP1 / Clients Win7 mit Outlook 2007-2013

 

Mails werden per POPCon abgeholt, der Exchange ist momentan nicht von extern erreichbar. Es werden aber Outlook sich per VPN verbinden und natürlich Smartphones mit der festen IP des DSL.

 

Es begann damit das ich Clients habe die nicht in der Domäne sind und Outlook nicht verbunden werden konnte. Meine Recherche ergab das ich das Autodiscover und das Zertifikat richtig erstellen muss. Nachdem ich ein neues Zertifikat erstellt habe, bekomme ich bei den Clients die in der Domäne sind die Meldung das ein Problem mit dem Zertifikat des Proxy vorliegt und Benutzer und Kennwort wird abgefragt, die Anmeldung schlägt aber fehl.

 

Outlook Anywhere sieht so aus:
Externer Host ist leer (Was sollte da rein? VPN Clients werden sich mit dem internen Servernamen verbinden)
Interner Host "Server.dom.local"
Authtifizierung "Aushandeln"

SSL ist zugelassen

 

Ich bin mir sicher das ich einen Bock bei den Werten für das Zertifikat gebaut habe. Kann mir jemand sagen was in meinem Fall für Werte gesetzt werden müssen für:

 

Outlook Web App intern/extern
OAB intern/extern
Exchange Webdienste intern/extern

Active Sync intern/extern

Autoermittlung intern/extern
POP

IMAP

Outlook Anywhere

 

 

Danke vorab!



 

[RobertWi 81]

Es begann damit das ich Clients habe die nicht in der Domäne sind und Outlook nicht verbunden werden konnte. Meine Recherche ergab das ich das Autodiscover und das Zertifikat richtig erstellen muss. Nachdem ich ein neues Zertifikat erstellt habe, bekomme ich bei den Clients die in der Domäne sind die Meldung das ein Problem mit dem Zertifikat des Proxy vorliegt und Benutzer und Kennwort wird abgefragt, die Anmeldung schlägt aber fehl.

 

Dann sorge zuerst dafür, dass die Clients keinen Zertifikatsfehler bringen. Outlook reagiert empfindlich auf Störungen im SSL und bei Problemen mit dem Zertifikat geht irgendwas nicht.

 

Zum Testen kannst Du das Stammzertifikat der CA beim Client importieren aber langfristig wird es wohl auf ein externes Zertifikat hinauslaufen, dem die Clients von sich aus vertrauen.

 

 

Outlook Anywhere sieht so aus:

Externer Host ist leer (Was sollte da rein? VPN Clients werden sich mit dem internen Servernamen verbinden)

 

Dann kommt hier der "interne" Name rein. Wenn Du wie empfohlen SplitDNS benutzt, da ist der Name in beiden Feldern identisch.

 

VPN nur für Outlook ist überflüssig, das bringt außer mehr Komplizität kaum mehr Sicherheit. Aber wenn die Clients noch andere Dinge im Netz machen sollen, kann natürlich auch Outlook via VPN laufen.

 

Ich bin mir sicher das ich einen Bock bei den Werten für das Zertifikat gebaut habe. Kann mir jemand sagen was in meinem Fall für Werte gesetzt werden müssen für:

 

Das ist vollkommen egal. Im Zertifikat stehen nur Namen, keine differenzierten Funktionen (bzw. steht da eine Funktion, die man für alles braucht - SSL). Zumal beim guten Design eh nur maximal 2 Namen drin stehen.

 

Ich persönlich ignoriere diese "Assistenten" und seine Vorschläge daher meist und trage die erforderlichen Namen direkt von Hand ein.

[=BT=Viper 11]

Danke schonmal für diese Info! Das ich das Zertifikat bei den Clients importieren muss ist klar. Kann ich ja auch per GPO verteilen. (Ich hab übrigens keine CA sondern nutze die von Exchange selbst signierten.)

Trage ich für den externen Host bei Outlook Anywhere den FQDN oder nur den Servernamen ein?

Beim Zertifikat stellt sich für mich dennoch die frage was ich für die externen Zugriffe eintrage. Wenn dann wird ja mit der festen IP des ISP zugegriffen, oder per VPN auf den Namen. Also auch der interne FQDN?
Und bei den internen Sachen incl. POP IMAP, OA auch der FQDN? Der Assistent schlägt hier den reinen Servernamen vor, ohne Domäne.

[NorbertFe 2.041]

BEi Split-DNS steht sowohl intern als auch extern jeweils das gleiche drin. Der FQDN des konfigurierten Zugriffsnamen (das muß/sollte nicht unbedingt der Servername sein).

 

Bye

Norbert

[RobertWi 81]

Danke schonmal für diese Info! Das ich das Zertifikat bei den Clients importieren muss ist klar. Kann ich ja auch per GPO verteilen. (Ich hab übrigens keine CA sondern nutze die von Exchange selbst signierten.)

 

Ich denke, die Clients sind nicht in der Domäne? Dann wird das mit den GPO etwas komplizierter.

 

Self-Signed Zertifikate sollten nicht benutzt werden. Diese sind nicht vollständig supported, können bei jedem Updates nicht mehr funktionieren und die Smartphones wollen die je nach Gerät überhaupt nicht.

 

Beim Zertifikat stellt sich für mich dennoch die frage was ich für die externen Zugriffe eintrage. Wenn dann wird ja mit der festen IP des ISP zugegriffen, oder per VPN auf den Namen. Also auch der interne FQDN?

Und bei den internen Sachen incl. POP IMAP, OA auch der FQDN? Der Assistent schlägt hier den reinen Servernamen vor, ohne Domäne.

 

Das hat Dir ja Norbert schon geschrieben, beui SplitDNS ist es interne via extern der gleiche Name.

 

Und nochmal zur Wiederholung: Ignoriere den Vorschlag des Assistenten!

[=BT=Viper 11]

Hmmm..... ich habe den internen FQDN beim OA hinterlegt. Autodiscover funktioniert auch. Ich habe ein neues Zertifikat erstellt und überall Server.domäne.local eingetragen, bis auf die eine Stelle wo Autodiscover.dom.local drin steht.

Wenn ich Outlook neu öffne kommt die Meldung das ein Problem mit dem Sicherheitszertifikat des Proxyservers vorliegt. Der Name entspricht nicht der Zielwebseite "Servername" (nicht der FQDN). Fehlercode 10

Das Zertifikat habe ich bei den vertrauenswürdigen Stammzertifizierungsstellen importiert.

Zumindest kommt jetzt nicht mehr der Fehler das ein Login Fenster aufpoppt.

 

 

Nur einige Clients werden nicht in der Domäne sein.
 

bearbeitet 18. Juni 2014 von =BT=Viper

[RobertWi 81]

Du musst natürlich auch noch die diversen URLs bei den virtuellen Verzeichnissen korrekt einstellen.

[=BT=Viper 11]

Die stehen korrekt drin, also z.B. https://server.dom.local/owa

Aber ich hab mich zu früh gefreut, dass Login Fenster kommt doch wieder. Denke das hängt mit der Proxyfehlermeldung zusammen.

Komisch, der Fehler tritt gerade nur an meinem testPC auf. Bei den anderen Usern nicht sobald der Zertifikat importiert wird. Ich kann dann auch nicht auf die Öffentlichen Ordner zugreifen. Mit welchem User ich es versuche ist egal.

bearbeitet 18. Juni 2014 von =BT=Viper

[=BT=Viper 11]

Einen NichtDomänenClient konnte ich verbinden. Autodiscover und Zertifikat wurden wie oben beschrieben erstellt, danke!

Ich musste noch in den Verbindungseigenschaften von Outlook den FQDN des Exchange als Proxy hinterlegen. Jedoch sehe ich keine öffentlichen Ordner. (Diese liegen in einer anderen DB)

 

Dazu kommt noch, dass ich bei Outlook 2013 noch immer die Meldung bekomme, dass ein Problem mit dem Sicherheitszertifikat des Proxy besteht. Und ein Loginfenster erscheint. Ich kann eingeben was ich will, bringt nix. Ich kann die ÖOs auch nicht erweiten. Meldung: Der Ordner kann nicht erweitert werden. MS Exchange ist nicht verfügbar... Es gibt hierzu Hotfixe vom August 2013, die waren aber schon installiert.

Also es ist echt seltsam! Ich habe hier auch ein Outlook 2013 das sich problemlos verbindet. Ich komme auch ohne Gemecker auf die ÖO. Das Zertifikat wird mittlerweile per GPO verteil.

 

Ich habe mir im Outlook mal die Verbindungseigenschaften angesehen, alles identisch. Hat da noch jemand eine Idee?

[=BT=Viper 11]

Also ich habe noch immer ein Problem mit den externen Clients die nicht in der Domäne sind. Die bekomme ich nicht an den Exchange ran.

 

In der Hosts Datei hab ich den Servernamen und den FQDN hinterlegt. Wobei mir aufgefallen ist das der Server mit 27c5b8ec-a860-4e1a-95e6-e0794444bf98@domäne.local bei den Clients hinterlegt ist. Das kann ja so nicht funktionieren. wobei ich diesen Namen nirgends hinterlegt habe.

 

[RobertWi 81]

Moin,

 

der Server-Name ist korrekt so. Die Verbindung wird ja via Outlook Anywhere zum CAS ausgebaut.

 

Servername und FQDN in der Hosts-Datei ist überflüssig, und fehlerträchtig - dafür ist DNS da.

[NorbertFe 2.041]

Liest eigentlich irgendjemand die Doku bevor er ein neues Produkt einführt? ;) Die ID die du da siehst ist die Mailbox-GUID des jeweiligen Postfachs. Da steht also kein Servername mehr drin, wie bis Version 2010. Und mit Hosts Dateien würde ich gar nicht erst anfangen, das wird dir über kurz oder lang auf die Füße fallen. Was sagt: https://testconnectivity.microsoft.com/

 

Bye

Norbert

[=BT=Viper 11]

Hi, ich muss das Thema doch nochmals aufgreifen...

 

Prinzipiell funktioniert der Exchange prima. Ich habe nur ein Problem, Clients die nicht in der Domäne sind sehen die öffentlichen Ordner und auch das Compilance Archiv nicht. Beide Bereiche sind in eigenen Datenbanken.

Outlook und die Ereignisanzeige melden keine Fehler.

Eine Überlegung habe ich noch... Ich habe mir mein Zertifikat nochmals angeschaut. Hier stehen momentan folgende Antragstellernamen drin:

exchange01.domäne.local

AutoDiscover.Domäne.local

AutoDiscover.Domäne.de

Domäne.local

Domäne.de

 

Was mir momentan darin fehlt ist:

 

exchange01

die öffentliche IP

 

Wobei der Zugriff mit iPhones von extern problemlos funktioniert und die externen Outlook momentan per VPN zugreifen. Daher glaube ich kaum das es daran liegen kann.

[NorbertFe 2.041]

Öffentliche Ordner und Online Archiv brauchen zwingend ein funktionierendes Autodiscover. Iphones: Schön, dass die funktionieren, aber das hat leider nur begrenzte Aussagekraft für Outlook, da der Zugriff vollkommen anders funktioniert (ausser dass beide Zugriffe https benutzen. ;)). Weiterhin wird für Outlook dann auch die korrekte Lizenz benötigt. Und warum nutzt du jetzt auf einmal VPN für Outlook? Siehst du da dann die ÖO und Archive?

 

Bye

Norbert

[=BT=Viper 11]

Selbst wenn ich einen Client im LAN habe der kein Domänenmitglied ist bekomme ich die ÖO nicht angezeigt.