none
Exchange 2007 OWA Proxy Fehlermeldung (401 not authenticated) RRS feed

  • Frage

  • Hallo Gemeinde,

    ich bekomme bei der Anmeldung an meinem OWA Frontend-Server öfters eine Proxy Fehlermeldung (MSExchange OWA Event 71 - 401 not authenticated). Laut KB soll dies ja mit einem Kerberos-Problem zu tun haben.

    Beide EX2007 sind auf demselben Versionsstand, ein Zugriff per IE auf den OWA des internen Servers funktioniert einwandfrei. Es kommen keine Warnungen wegen Zertifikatefehlern usw.

    Das Problem verschwindet auch temporär, wenn ich auf dem Frontend-Server ein IISRESET ausführe. Im Eventlog auf beiden Servern finden sich sonst keine Warnungen oder Fehlermeldungen.

    Vielen Dank,
    Matthias.

    Dienstag, 7. Dezember 2010 10:00

Antworten

  • Hallo zusammen,

    ich habe am WE auf beien CAS-Servern die CAS-Rolle noch einmal deinstalliert / neuinstalliert. Seitdem ist der Fehler verschwunden.

    Trotzdem vielen Dank für Eure Bemühungen!

    /matthi.

    Montag, 13. Dezember 2010 11:32

Alle Antworten

  • Hi,

    bei Exchange 2007 gibts eigentlich keinen OWA-Frontend - Server mehr. meinst du die CAS-Rolle?

    Hast du einen Proxy - Server im Einsatz? Wenn ja, ist der Exchange in der Ausnahmeliste im Browser eingetragen?


    Viele Grüße Walter Steinsdorfer MVP Exchange Server http://msmvps.com/blogs/wstein/
    Dienstag, 7. Dezember 2010 10:22
    Moderator
  • Hi,

    also, ich habe zwei Exchange 2007 CAS. Einer steht intern, der zweite innerhalb einer DMZ - dieser ist für den Zugriff von Außen vorgesehen und konfiguriert (internal und external URL). Der Zugriff funktioniert auch tadellos, aber nach ein paar Minuten bis Stunden erscheint nach der Anmeldung am DMZ CAS die o.g. Fehlermeldung. Nach einem IISRESET auf dem DMZ CAS funktioniert auch alles wieder einwandfrei.

    Nur im DMZ CAS sehe ich im Applicastion Eventlog einen Eintrag über MSExchange OWA Event 71. Leider sind die angegebenen Schritte für eine Fehlerkorrektur bei mir leider nicht hilfreich, da es sich nicht um ein permanentes Problem handelt.

    Viele Grüße,
    Matthias.

    Mittwoch, 8. Dezember 2010 07:10
  • Hi Matthias,

    ich gehe davon aus, dass auf dem inneren CAS SSL nicht erzwungen ist und die
    Windows Auth. genutzt wird?:
    http://msexchangeteam.com/archive/2007/09/04/446918.aspx
    http://technet.microsoft.com/en-us/library/bb310763.aspx#proxyoverview

    Du hast geschrieben, dass beide Server den gleichen Versionsstand haben - ist
    das SP3?

    Sind beide Server in der gleichen AD-Site - ich frage mich, ob die Anfragen
    grundsätzlich zum internen CAS weitergeleitet werden oder direkt zum Mailbox
    gehen, weil er sich verantwortlich fühlt.

    Eigentlich würde ich sagen, dass eine TMG in der DMZ besser wäre und intern
    beide Server als CAS-Array laufen sollten...

    Viele Grüße
    Christian

    Mittwoch, 8. Dezember 2010 10:06
    Moderator
  • Moin,

    ich tippe auch darauf, das der DMZ-CAS die Anfragen direkt an den Mailboxserver weiterleitet. Der CAS kommuniziert mit der Mailbox-Rolle über RPC. Welche Ports hast du zwischen dem CAS und der Mailbox-Rolle freigegeben ?

    Ich kann Christian Tipp mit dem TMG noch mal unterstützen. Damit hast du weniger Probleme und einen höhere Sicherheit. Das TMG stellst du dann am besten in die DMZ. Die Clients landen beim Aufruf der Seite erst mal auf dem TMG. Dort wird erst eine Authentifizierung des Benutzers durchgeführt und dann wird der SSL-Tunnel unterbrochen. TMG kann jetzt den Content überpfüfen. Wenn der Content zu OWA passt, wird eine neue SSL-Verbindung zum internen CAS aufgebaut. Der spricht dann mittels RPC wieder mit dem Mailbox-Server. In diesem Fall brauchst du nur HTTPS vom TMG bis zur CAS-Rolle freigeben.

    Die Authentifizierung am TMG kannst du entweder über AD machen, oder über LDAP. Im ersten Fall muss TMG in die Domäne aufgenommen werden. Das geht am einfachsten mit zwei Adaptern am TMG. Einer in der DMZ und der zweite im LAN. Dann brauchst du keine Ports mehr zwischen DMZ und LAN öffnen.

    Bei LDAP musst du 389 vom TMG auf die DCs erlauben. (geht auch mit LDAPS)

    Denn freigewordenen CAS kannst du dann intern verwenden und aus beiden Servern einen NLB-Cluster bauen ;)

     


    Viele Grüße Carsten
    Donnerstag, 9. Dezember 2010 06:57
  • Hallo Christian,

    beide Server sind auf EX2007 SP3. Auf dem innernen CAS wird SSL nicht erzwungen, ist aber konfiguriert. Der Zugriff im LAN funktioniert sowohl per HTTP als auch HTTPS (ohne Zertifikatswarnmeldungen). Auch der externe CAS kann auf den OWA ohne Fehlermeldungen zugreifen.

    Die Server stehen jeweils in einer eigenen AD-Site, die entfernte AD-Site hat den externen CAS, der auch aus dem Internet angesprochen werden kann. Der externe CAS ist auch DC für diese Site.
    Der Zugriff im OWA erfolgt auch per CAS to CAS Proxy und nicht per direktem MBX Zugriff (das sehe ich im Wireshark und in den IIS Logs des inneren CAS). Generell dürfen sich aber beide Exchange Server uneingeschränkt unterhalten (ist jetzt so zur Fehlersuche eingerichtet).

    Was mich wundert ist, dass es nach einem IISRESET auf dem externen CAS einwandfrei funktioniert und nach mehreren Zugriffen auf einmal nach der Anmeldung beim externen CAS (Form based) folgenden Fehler gibt:

    Request
    Url: https://EXTERNER.CAS.INTERNET:80/owa/ev.owa?oeh=1&ns=HttpProxy&ev=ProxyRequest
    User host address: 111.222.333.444
    User: Matthias Läßig
    EX Address: /o=BPAD/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=mla
    SMTP Address: mla@apob.net
    OWA version: 8.3.106.1
    Second CAS for proxy: https://ex2007.de.internal.net/owa

    Exception
    Exception type: Microsoft.Exchange.Clients.Owa.Core.OwaProxyException
    Exception message: The proxy CAS failed to authenticate to the second CAS (it returned a 401)

    Call stack

    No callstack available

    Inner Exception
    Exception type: Microsoft.Exchange.Clients.Owa.Core.OwaAsyncOperationException
    Exception message: ProxyPingRequest async operation failed

    Call stack

    Microsoft.Exchange.Clients.Owa.Core.ProxyPingRequest.EndSend(IAsyncResult asyncResult)
    Microsoft.Exchange.Clients.Owa.Core.ProxyEventHandler.SendProxyPingRequestCallback(IAsyncResult asyncResult)

    Inner Exception
    Exception type: System.Net.WebException
    Exception message: The remote server returned an error: (401) Unauthorized.

    Call stack

    System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
    Microsoft.Exchange.Clients.Owa.Core.ProxyUtilities.EndGetResponse(HttpWebRequest request, IAsyncResult asyncResult, Stopwatch requestClock)
    Microsoft.Exchange.Clients.Owa.Core.ProxyPingRequest.GetResponseCallback(IAsyncResult asyncResult)

    Auf dem internen CAS sehe ich dann auch im Security Eventlog einen Eintrag mit Kerberos Authentication failed mit einer NULL SID.

    Viele Grüße,
    /matthi.

    Donnerstag, 9. Dezember 2010 15:05
  • Ich hatte einmal ein Ähnliches Problem. In dieser Konstellation war eine SonicWAll (jaja ich weiss :)) dazwischen geschaltet; also zwischen DMZ und LAN. Das Problem konnte ich lösen, indem ich die Gültigkeit der TCP-Session Dauer auf der Policies erhöht habe.
    Donnerstag, 9. Dezember 2010 17:36
  • Hi Andy_ch,

    Ich hatte einmal ein Ähnliches Problem. In dieser Konstellation war eine SonicWAll (jaja ich weiss :)) dazwischen geschaltet; also zwischen DMZ und LAN. Das Problem konnte ich lösen, indem ich die Gültigkeit der TCP-Session Dauer auf der Policies erhöht habe.

    wenn das Problem immer mal wieder auftritt, würde ich auch in die Richtung
    tendieren. Welche Fw wird denn eingesetzt?

    Viele Grüße
    Christian

    Freitag, 10. Dezember 2010 06:40
    Moderator
  • Hi Andy_ch und Christian,

    im Moment ist da nur noch ein IPSEC Tunnel (IKEv2) zwischen den beiden Subnetzen. Die Kommunikation kann ungehindert stattfinden. Sowohl IPv4 als auch IPv6 sind eingerichtet und funktionieren.

    Aufgrund des Eintrags auf dem inneren CAS tippe ich eher darauf, dass der äußere CAS mit einem veraltetet (oder ungültigen) Kerberos Ticket daherkommt. Die Frage ist nun, wie debuggt man sowas?
    Kann man im Exchange für den OWA das Loglevel hochschrauben?

    Viele Grüße,
    /matthi.

    Freitag, 10. Dezember 2010 08:39
  • Hi matthi,

    ich glaube, dass die Fehlermeldung am inneren Hub dnn anders lauten
    müsste...mmh

    Dann schau mal ein wenig in die Richtung und teste auch mal mit NTLM statt
    Kerberos:
    Behandeln von Problemen in Verbindung mit Kerberos in IIS
    http://support.microsoft.com/kb/326985

    Troubleshooting Kerberos Problems
    http://technet.microsoft.com/de-de/library/cc786325%28WS.10%29.aspx

    Vielleicht auch interessant:
    Understanding Kerberos Double Hop
    http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx

    Viele Grüße
    Christian

    Freitag, 10. Dezember 2010 09:02
    Moderator
  • Hallo

    Also bei 2 AD Sites sollen die CAS Sever auch Proxy machen.

    Hier nochmal wie bereits von Christian zu Exchange 2007.

    http://technet.microsoft.com/en-us/library/bb310763(EXCHG.80).aspx

    Proxying for Outlook Web Access

    The following scenario illustrates how incoming requests are handled for a user who connects to an Exchange 2007 Client Access server named CAS-01 by using Outlook Web Access.

    1. The Client Access server queries Active Directory to determine the location of the user's mailbox and the version of Microsoft Exchange that is installed on the Mailbox server. If the user's mailbox is on an Exchange 2007 Mailbox server, go to step 3.
    2. If the user's mailbox is on an Exchange 2003 server and the user tried to access Outlook Web Access by using https://domain name/owa, they will receive an error. If the user tries to access https://domain name/exchange or https://domain name/public, the incoming request is proxied to the Exchange 2003 server that hosts the user's mailbox and the Outlook Web Access virtual directory. If the incoming request is to an Exchange 2007 Client Access server in a different Active Directory site than the destination back-end server, the request will be proxied to the destination back-end server directly, even if there is an Exchange 2007 Client Access server within the destination Active Directory site. If the incoming request is to an Exchange 2007 Client Access server within the same Active Directory site as the destination back-end server, the request will be proxied directly to the destination back-end server. In this case, skip step 3.

    3. If the user's mailbox is on an Exchange 2007 mailbox server, CAS-01 locates a Client Access server that is in the same Active Directory site as the user's mailbox server. When one is found, Exchange 2007 determines whether the Client Access server has the InternalURL property configured and if the authentication method on the virtual directory is set to Integrated Windows authentication. CAS-01 then determines whether an external URL is specified. If so, the user is redirected to the server that is specified by the ExternalURL property. If an external URL is not specified, CAS-01 will proxy the user's request to the Client Access server that is specified by the InternalURL property.

    Bb310763.note(en-us,EXCHG.80).gifNote:

    An internal URL is configured automatically during Exchange 2007 Setup. The default value of the ExternalURL property is $null. For Internet-facing Client Access servers, the ExternalURL property should be set to the value published in DNS for that Active Directory site. For Client Access servers that do not have an Internet presence, the ExternalURL property does not need to be configured.

    - Auf dem internen CAS Server dürfte also FBA nicht aktiv sein, da muss Windows integratet sein

    - ExternalURL auf dem internen CAS sollte $null sein

    - InternalURL auf dem internen CAS sollte https://servername/owa sein

     


    Viele Grüsse Georg Flühmann
    Freitag, 10. Dezember 2010 09:19
  • Hallo Georg,

    ja, es ist alles nach Anleitung eingerichtet und funktioniert ja auch - nur leider nicht besonders stabil. Nach einem IISRESET auf dem externen CAS tut es und es stellt sich langsam so dar, als ob ich mich nur ein einziges mal anmelden könnte und dann bekomme ich den o.g. Fehler.

    Mittlerweile habe ich einen Schedules Task eingerichtet, der IISRESET ausführt, wenn der MSExchange OWA Event 71 auftritt. Das geht als Workaround erst einmal, ist aber nicht besonders schön.

    BTW: EAS und IMAP ist davon nicht betroffen - bei IMAP war lediglich im .config ein Wert zu setzen (das wurde in einem der SPs mal geändert)

    Freitag, 10. Dezember 2010 09:31
  • Und es kann auch nicht sein das OWA Redirected wird anstatt Proxy macht. Lies dazu mal den Teil unter Configuring Redirection

    im Technet Artikel. Dieses verhalten kann deaktiviert werden:

    set-owavirtualdirectory "owa (default web site)" -RedirectToOptimalOWAServer $false

    Weitere Punkte die mir noch schweben:

    - Sind die SPNs auf den CAS Servern registriert

    - Der interne CAS Server unterstützt keine Kerberos Auth.

    - Loadbalancing der CAS Rollen (du hast aber ja immer nur 1 CAS Server pro AD Site)

    - GCs vorhanden in beiden AD Sites

    Könntest du mal ein Get-OwaVirtualDirectory der beiden CAS Server posten?

     


    Viele Grüsse Georg Flühmann
    Freitag, 10. Dezember 2010 11:33
  • Hi,

    Das betreiben von CAS-Servern in einer DMZ ist wegen der notwendigen RPC-Zugriffe eigentlich Unsinnig und von Microsoft nicht supportet. Wenn du einen sicheren Zugang haben möchtest dann ist TMG oder UAG das richtige Stichwort.

    Vielleicht kannst du uns mitteilen wie du auf diese spezielle Konfiguration kommst? Wenn du die eingekauft hast sollte jemand mit dem Berater sprechen...

    Just my 2 Cents.


    Viele Grüße Walter Steinsdorfer MVP Exchange Server http://msmvps.com/blogs/wstein/
    Freitag, 10. Dezember 2010 12:59
    Moderator
  • Hallo zusammen,

    ich habe am WE auf beien CAS-Servern die CAS-Rolle noch einmal deinstalliert / neuinstalliert. Seitdem ist der Fehler verschwunden.

    Trotzdem vielen Dank für Eure Bemühungen!

    /matthi.

    Montag, 13. Dezember 2010 11:32