Benutzer mit den meisten Antworten
Exchange 2007 OWA Proxy Fehlermeldung (401 not authenticated)

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.
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.
- Als Antwort markiert Christian SchulenburgModerator Montag, 13. Dezember 2010 19:01
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/ -
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. -
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#proxyoverviewDu 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 -
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 -
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/owaException
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 failedCall 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. -
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.
-
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 -
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. -
Hi matthi,
ich glaube, dass die Fehlermeldung am inneren Hub dnn anders lauten
müsste...mmhDann 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/326985Troubleshooting Kerberos Problems
http://technet.microsoft.com/de-de/library/cc786325%28WS.10%29.aspxVielleicht auch interessant:
Understanding Kerberos Double Hop
http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspxViele Grüße
Christian -
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 AccessThe 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.
- 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.
- 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.
Note:
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 -
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)
-
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 -
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/ -
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.
- Als Antwort markiert Christian SchulenburgModerator Montag, 13. Dezember 2010 19:01