Exchange, Autodiscover, Zertifikate und Outlook 2010 - Hilfe

[BDS_ABO 0]

Hallo liebe Community,

 

ich wende mich an Euch, da ich alleine nicht mehr weiter komme. Bei uns ist ein neuer Kunde mit einem Netzwerk, dass er über Jahre mit Wissen und Halbwissen aufgebaut hat. Jetzt haben wir uns einen Überblick verschafft und ich stoße auf ein Problem, das ich alleine nicht gelöst bekomme:

 

Der Kunge betreibt einen Exchange 2010 Servermit OWA

Port 443 ist von der Firewall durchgeleitet

Auf der Domäne Kunde.de gibt es den srv-Eintrag _autodiscover._tcp.kunde.de auf mail.kunden.de sowie einen cname autodiscover.kunde.de, der auf mail.kunde.de verweist.

Das Zertifikat ist ausgestellt auf *.kunde.de

 

Folgendes Phänomen:

Nehme ich meinen Test-Laptop (nicht Mitglied der Domäne, standard DSL-Leitung, ungefiltert), installiere Outlook 2010 und richte das Konto ein, funktioniert autodiscover einwandfrei, alle Daten werden aus der Ferne gefunden und aufgelöst, nach einer Amneldung und dem Akzeptieren eines Zertifikates (warum?) kann ich normal arbeiten auf dem Exchange.

 

Jeder andere Domänen-PC kann nicht per owa auf den Exchange connecten. "Das Postfach steht nicht zur Verfügung".

Ich dachte, ein Zertifikat liegt evtl. quer, aber ich habe einem Domänen-PC mal testweise alle Zertifikate gelöscht, die irgendwie "kunde.de" hießen. Auch kein Erfolg.

Ich weiß leider auch nicht, wie ich genau analysiere kann, WAS GENAU da quer liegt.

 

Der srv-lookup von mxtoolbox sagt "no record exists". Ist das überhaupt richtig?

 

von https://testconnectivity.microsoft.com/ bekomme ich bei "Outlook Autodiscover" alles grün außer zwei Einträge:

1.
Analyzing the certificate chains for compatibility problems with versions of Windows.
     Potential compatibility problems were identified with some versions of Windows.
     
    Additional Details
     
The Microsoft Connectivity Analyzer 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.
Elapsed Time: 2 ms.

2.
Testing TCP port 443 on host kunde.de to ensure it's listening and open.
     The specified port is either blocked, not listening, or not producing the expected response.
      Tell me more about this issue and how to resolve it
     
    Additional Details
     
A network error occurred while communicating with the remote host.
Elapsed Time: 1835 ms.

Dass die Domäne Kunde.de auf 443 nicht erfolgreich ist, ist klar, denn da ist eine andere IP hinter, als hinter mail.kunde.de aber was besagt der erste Eintrag?

Kann da jemand halfen?
Was ist mein Problem, warum geht das mit unternehmensfremden Laptops, aber nicht unternehmeneigenen?

 

 

 

[Sanches 22]

Hallo und willkommen im Board,

 

ist beim Kunden SplitDNS (korrekt) eingerichtet?

 

Gruß Sebastian

[BDS_ABO 0]

Hallo und willkommen im Board,

 

ist beim Kunden SplitDNS (korrekt) eingerichtet?

 

Gruß Sebastian

Meines Wissens nach nicht eingerichet. Auch nicht benötigt, intern heißt das netz kunde.local

[testperson 1.680]

Hi,

 

in dem Fall wird es zwingend benötigt, da das Wildcard (*.kunde.de) wohl keinen Host exchange.kunde.local o.ä. beinhaltet bzw. "abdeckt".

 

Gruß

Jan

[NorbertFe 2.035]

Und wieso wird es dann nicht benötigt? Genau deswegen sollte es ja eingerichtet werden. Zum Thema Split-DNS, Autodiscover, Service Records gibt's hier im Board allein dieses Jahr schon gefühlt 10 Threads. ;)

[Sanches 22]

Hi,

 

hm, dein Zertifikat ist auf *.kunde.de ausgestellt, lokal nutzt du kunde.local Adressen.

Das wird zu Zertifikatsproblemen führen, wenn du intern darauf zugreifst.

Von extern siehst du (bzw. dein Client) ja nur die externen .de Adresse, welche korrekt im Zertifikat hinterlegt sind.

 

Gruß Sebastian

[BDS_ABO 0]

Und wieso wird es dann nicht benötigt? Genau deswegen sollte es ja eingerichtet werden. Zum Thema Split-DNS, Autodiscover, Service Records gibt's hier im Board allein dieses Jahr schon gefühlt 10 Threads. ;)

 

Hi,

 

hm, dein Zertifikat ist auf *.kunde.de ausgestellt, lokal nutzt du kunde.local Adressen.

Das wird zu Zertifikatsproblemen führen, wenn du intern darauf zugreifst.

Von extern siehst du (bzw. dein Client) ja nur die externen .de Adresse, welche korrekt im Zertifikat hinterlegt sind.

 

Gruß Sebastian

ich habe intern keine Probleme. Auch mit VPN funktioniert alles.

nur extern macht Ärger und auch NUR bei den Firmen-Notebooks. Bei meinerm Testnotebook (Standard Windows 10, keine Domänenmitgliedschaft) geht alles. Und ich komme auch von extern.

[NorbertFe 2.035]

Du kannst natürlich weiter diskutieren, nur wird das nichts daran ändern, dass dir die überwältigende Mehrheit sagen wird: Machs richtig, dann hast du weder innen noch aussen Probleme.

[BDS_ABO 0]

Ich möchte nicht diskutieren, versteh mich bitte nicht falsch. Ich blicke schlichtweg nicht mehr durch. Das Thema Split-DNS ist nicht ganz meins ;)

Was muss ich tun, um es richtig zu machen?

 

Nachtrag: ein Kollege von mir hat bemerkt, dass intern kein srv-Eintrag auf autodiscover.kunde.de gesetzt war. Wir haben den jetzt gesetzt auf mail.kunde.de

Es gab jedoch einen A-Eintrag autodiscover.azs.de, der ebenfalls auf mail.azs.de verwies.

[NorbertFe 2.035]

Man braucht insgesamt keinen SRV Record. Und solange auf der Ebene eben immer nur rumprobiert wird, wird's schwer da Verständnis reinzubringen.

 

Wenn intern einen A Record für autodiscover.kunde.de existiert der auf die intern IP des Exchangeservers zeigt war alles richtig und der SRV Record ist überflüssig, weil den niemand fragt. Ausnahme du hast den Namen autodiscover.kunde.de nicht im Zertifikat. Wenn das der Fall ist, geht's aber logischerweise auch von aussen nur per SRV Record. Da den aber nicht alle Clients auswerten sollte man eben Split-DNS und A Record für Autodiscover und entsprechende Namen im Zertifikat haben. Ausserdem internalURL und externalURL bei allen virtuellen Verzeichnissen auf den externen Namen (mail.kunde.de) setzen fertig!

 

Bye

Norbert

bearbeitet 24. Februar 2017 von NorbertFe

[Sanches 22]

@TO: Du solltest noch in deinem letzten Beitrag die Adressen anonymisieren.

 

Gruß Sebastian