Beiträge von cneue

    Noch was vergessen:


    die zuvor beschriebene Variante mit dem ausschalten des Loopback-Checks ist nicht für produktive, sondern nur für Testumgebungen zu empfehlen.


    in einer Produktivumgebung sollte man diese Variante anwenden: Im Regeditor unter folgendem Abschnitt


    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0


    einen neuen Multi-String-Eintrag mit Name “BackConnectionHostNames“ anlegen
    den betroffenen Hostheader (zb. wie in meinem Fall mx.MEINEDOMAIN.com) als Wert eintragen. ...und fertig


    ansonsten wird die Sicherheit des Systems gefährdet und man macht das System für eine Refelction-attack anfällig.


    So oder so ähnlich konnte ich es noch einmal nachrecherchieren.


    So, das war's

    Hallo Robert,


    du wirst es nicht glauben aber das Problem ist gelöst! Am Host-Header lag es auch nicht. Ich habe gefühlt das ganze WWW nach diesem Authentifizierungsproblem durchsucht und bin dann auf einen Beitrag/Artikel gestoßen.


    Das Problem war ein loopback-check. Hier der link zum Artikel:


    http://clintboessen.blogspot.d…sue-401-unauthorized.html


    Folgendes habe ich durchgeführt:


    This is caused by the loopback check being enabled. To disable loopback perform the following action on the client access servers:


    1.Click Start, click Run, type regedit, and then click OK.
    2.In Registry Editor, locate and then click the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    3.Right-click Lsa, point to New, and then click DWORD Value.
    4.Type DisableLoopbackCheck, and then press ENTER.
    5.Right-click DisableLoopbackCheck, and then click Modify.
    6.In the Value data box, type 1, and then click OK.
    7.Quit Registry Editor, and then restart your computer. (war nicht erforderlich)


    Now when you test autodiscover settings everything will work:


    ...und tatsächlich jetzt läuft Outlook/Autodiscover auch auf dem Server korrekt.


    Man kann die ganze Zertifikatsgeschichte (mit zb: .local-Domain und .com-Domain) also auch mit einem ganz normalen Standard-SSL-Zertifikat ohne SAN erledigen/lösen.


    Bleibt zuletzt nur noch die Frage ob diese Änderung an der Registry des Windows Servers irgendwelche negativen Auswirkungen an anderer Stelle haben. ...aber das wird sich in den nächsten Tagen zeigen.


    Dann wünsche ich allen, insbesondere Dir - Robert - ein schönes Weihnachtsfest... Vielen Dank für die Unterstützung

    habe ich soeben mal getestet: sowohl bei den client-PCs als auch am server funktioniert der aufruf von https://mx.MEINEDOMAIN.com/owa im browser problemlos.


    wenn ich mal ein nslookup mx.MEINEDOMAIN.com wird diese sowohl auf den client-PCs als auch auf dem server korrekt nach 10.0.1.1 aufgelöst. ich habe im dns eine zweite forward zone (MEINEDOMAIN.com) angelegt und dort einen A HOST (mx, nicht verwechseln mit MX-Record, der host heißt mx) hinzugefügt und bei der ip die interne server-ip 10.0.1.1 eingetragen.


    auffallend ist: wenn ich die InternalUrls vom autodiscover,ews,oab,unifiedmessaging von https://server.MEINEDOMAIN.local/XXXX auf https://mx.MEINEDOMAIN.com/XXXX setze, dann kommt (nur auf dem server) im Outlook die Benutzer/Passwort-Abfrage bzw. funktioniert das autodiscover nicht mehr.


    mache ich die änderung wieder rückgängig funktioniert autodiscover wieder (auf dem server - egal welcher benutzer).


    die probleme mit dem autodiscover bestehen nur auf dem server und immer nur dann , wenn er das autodiscover über https://mx.MEINEDOMAIN.com ausführt. mit server.MEINEDOMAIN.local funktioniert es.


    die frage ist jetzt warum die authentifizierung über https://mx.MEINEDOMAIN.com nicht funktioniert. namensauflösung kann es eigentlich nicht sein, weil siehe ganz oben.

    ...wäre es denkbar, dass es am zertifikat liegt? dieses ist für mx.MEINEDOMAIN.com ausgestellt.
    und outlook versucht anscheinend auf autodiscover.MEINEDOMAIN.com zuzugreifen, diese domain ist aber nicht im zertifikat enthalten.

    hallo robert,


    sehe ich genau so. ich habe es mit verschiedenen nutzerkonten versucht (administrator, benutzerkonto welches mitglied der administratoren ist, und einfaches benutzerkonto), leider habe ich immer den selben fehler.

    ähm versuch nochmal eine erklärung:


    mit clients meine ich PCs auf denen windows 7 und office installiert ist, diese PCs hängen alle in der domäne MEINEDOMAIN.local


    wie gesagt auf den PCs läuft alles problemlos, dort funktioniert outlook ohne zertifikatsfehler und autodiscover läuft auch.


    so, und dann gibt es da noch einen server (win2008r2 std. mit exchange 2007), auf diesem server ist auch office mit outlook installiert.
    und hier gibt es die besagten probleme, dass autodiscover nicht funktioniert.


    ...auf den Clientsläuft autodiscover, das heißt es werden die Einstellungen gefunden.


    Auf dem Server oder besser gesagt im Outlook auf dem Server funktioniert es nicht(ich habe Outlook 2007 auf dem Server installiert).


    Ich habe eine zweite Zone (Forward) im DNS angelegt (MEINEDOMAIN.com) und in dieser Zone manuell A Records (mx, server, autodiscover -> intern 10.0.1.1 UND www -> ext. IP)


    die Äuflösung funktioniert so auch korrekt, soll heißen mit nslookup kommt z.B. mx.MEINEDOMAIN.com - 10.0.1.1 und bei http://www.MEINEDOMAIN.com - ext. IP


    ich werde nochmal ein Screenshot vom "Outlook E-Mail Verbingseinstellungen testen" posten.

    Eigentlich habe ich gar nicht so viel konfiguriert. Folgendes habe ich gemacht:


    1. Standard SSL-Zertifikat erworben und installiert (kein SAN, für domain: mx.MEINEDOMAIN.com)
    -darauf hin kamen dann die Zertifikatsfehler bei den Clients, logisch, weil ja mx.MEINEDOMAIN.com ja abweicht von server.MEINEDOMAIN.local


    2. Aufgrund des Problems Zertifikatfehler den KB940726 durchgearbeit/ausgeführt mit den folgenden Befehlen:


    Set-ClientAccessServer -Identity SERVER -AutodiscoverServiceInternalUri
    https://mx.MEINEDOMAIN.com/autodiscover/autodiscover.xml


    Set-WebServicesVirtualDirectory -Identity "SERVER\EWS (Default Web Site)"-InternalUrl https://mx.MEINEDOMAIN.com/ews/exchange.asmx

    Set-OABVirtualDirectory -Identity "SERVER\oab (Default Web Site)"
    -InternalUrl https://mx.MEINEDOMAIN.com/oab


    Die Befehle wurden fehlerfrei ausgeführt.


    Jetzt waren die Zertifikatsfehler im Outlook 2007 auf den Clients weg, das Autodiscover läuft auf den Clients auch - keine Fehlermeldung etc. mehr


    Allerdings begann dann die Problematik auf dem Server selbst. Es kommt im Outlook immer eine Abfrage von Benutzer/Passwort. Außerdem funktioniert das Autodiscover nicht


    PS: Mit den SAN's wollte ich vermeiden, da ab ich glaube april 2015 keine Zertifikate mehr ausgestellt werden in denen eine .local-Domain enthalten ist/sein darf. Ich hätte das Problem dann ja nur verschoben. Das CA/Browser Forum empfiehlt daher die Umstellung .local -> .com bzw. eine FQDN mittels KB940726.


    Ich hoffe ich konnte einigermaßen nachvollziehbar darstellen, was ich gemacht habe.

    Hallo liebe Forum-Mitglieder,


    ich habe hier ein kleines Problem und bin so langsam mit meinem Latain am Ende. Vielleicht habt Ihr eine Idee? Folgendes Szenario:


    -Windows Server 2008 R2 mit Exchange 2007
    -Domäne meineDomäne.local ist eingerichtet, und wir haben ein Domain meineDomain.com
    - Exchange funktionierte bzw. funktioniert wunderbar


    Wenn man nun OWA genutzt hatte trat ein Zertifikatefehler auf. Darauf hin habe ich ein SSL-Zertifikat erworben und installiert. Problem danach war dann allerdings, dass im Outlook auf den Clients eine Zertifikatefehlermeldung kam. Ist ja logisch weil unterschiedliche Domain.
    SAN Zertifikate kamen nicht in Frage weil ab 2015 Schluss ist mit der Ausgabe von Zertifikaten mit .local-Domains.


    Darauf hin habe ich den KB940726 durchgearbeitet (Änderung der autodiscover SCP von .local auf zb. https://mx.meinedomain.com/autodiscover...../.... Danach funktionierten die Clients Problemlos (ohne Zertifikatswarnung, funktionierendes Autodiscover etc.)
    Auf dem Server selbst bekomme ich nun allerdings im geöffneten Outlook eine Aufforderung zur Eingabe von Benutzername/Passwort. Darüber hinaus funktioniert anscheinend auch kein Autodiscover, Outlook kann also keine Exchange Servereinstellungen finden.


    Habt Ihr vielleicht eine Idee wie ich das Problem gelöst bekomme?


    Ich bin dankbar für jeden Tip