Exch. 2007 .local->.com / kb940726

    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.

    ...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.

    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.

    • Offizieller Beitrag

    Moin,


    "mx.domäne" und "server.domäne" haben im internen DNS die gleiche IP-Adresse?


    Ich vermute, Du musst beim IIS auf dem Exchange auch mal einen Blick in die Bindungen werfen und dort eventuell den Hostheader anpassen. Der wird vermutlich nicht auf "mx.domäne" reagieren und dann landest Du auf dem Server auf einer falschen Webseite.

    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

    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