none
sporadisch Authentifizierung über RPC wiederholt nicht möglich

    问题

  • Hallo, folgendes Problem.

    Manchmal kann es vorkommen das sich Benutzer mit ihrem Outlook 2010 (über RPC angebunden) nicht Authentifizieren können, die Benutzeranmeldemaske kommt einfach immer wieder ohne das es passiert, es erscheint auch keine Fehlermeldung.
    Das einige was wir bisher herausgefunden haben ist das die die Anmeldung wieder funktioniert wenn man den IIS neu startet.

    Wenn man einen Test mit dem Microsoft Remote Connectivity Analyser Outlook Anywhere mit Autoermittlung macht funktioniert alles einwandfrei (keinen Fehler)

    Exchangeserver 2007 Version: 08.01.0436.000, läuft auf einem Windows 2008 Std. SP2

    Outlook Anywhere Anmeldung steht auf NTLM

    Die ganzen URL für die einzelnen Dienste habe ich auch schon mit einem funktionieren System verglichen und nichts festgestellt.

    Evtl. hat jemand einen Tipp

    Schöne Grüße

    2012年3月27日 10:29

答案

  • Die Notlösung war die Umstellung auf Standardauthentifizierung bei Outlookanywhere, scheinbar hat nur NTLM das Problem.
    2012年4月26日 14:32

全部回复

  • Hallo IT-Bändiger,

    ist das eine größere Umgebung? Wie viele Benutzer hast Du in etwa?

    Viele Grüße

    Timo


    2012年3月27日 10:54
    版主
  • Nein, ein Kleinbetrieb mit derzeit 8 aktiven Mailkonten.
    2012年3月27日 11:53
  • Hi IT-Bändiger,

    Dein Exchange 2007 ist sehr alt. (Kein Service Pack)

    Du solltest unbedingt eine Service Pack installation einplanen. (Backup vorher dann patchen)

    Ein solcher Fehler (kommende Login Boxen) wurde in einem Rollup (Rollup 9 for Exchange 2007 Sp1) behoben.

    Installiere SP3 dann solltest Du die Probleme los sein und es werden sicher noch einige weitere Seiteneffekte gefixt.

    SP3 hier: http://www.microsoft.com/download/en/details.aspx?id=24111

    VORSICHT: wenn Du Small Business hast, (stand oben nicht) dann hier beachten: http://support.microsoft.com/default.aspx?scid=kb;EN-US;974271


    Grüße, Christoph


    2012年3月27日 14:41
  • Das Servicepack habe ich gestern Abend installiert, heute morgen hat die erste Verbindung von Outlook über RPC funktioniert, ca. eine Std. später bei einem erneuten Test trat das alte Problem wieder auf (gleich nach dem Start von Outlook kommt das Authentifizierungsfenster, auch nach mehrmaligen eingeben der richtigen Benutzerdaten ist ein anmelden nicht möglich, keine Fehlermeldung)

    Parallel dazu habe ich die Anmeldung zu https://autodiscover.***.de/autodiscover/autodiscover.xml getestet mit dem gleichen Benutzer wie bei der Outlookanmeldung, dies funktioniert.

    Nach iisreset /reset auf dem Server funktioniert die Authentifizierung sofort wieder.

    2012年3月28日 7:39
  • schau doch mal im HTTPErr Log ("C:\Windows\System32\Logfiles\HTTPErr\"), ob Du da irgendwelche Hinweise findest.

    2012年3月29日 20:50
    版主
  • Hallo IT-Bändiger,

    versuche auf dem Exchange Server einmal folgenden Reg-Key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters   neuer DWord:
    Name: MaxWorkItems
    Type: REG_DWORD
    Value :8192 (decimal)

    Dann IIS und die Exchange-Systemaufsicht neu starten, dann sollte Dein Fehler weg sein.


    Grüße, Christoph

    2012年3月31日 13:31
  • Im HTTPERR LOG befinden sich immer wieder Meldungen wie:

    2012-03-30 07:00:12 84.155.151.65 55434 10.104.1.11 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?DC01.Domäne.local:6002 400 1 BadRequest DefaultAppPool
    2012-03-30 07:01:06 84.155.151.65 55434 10.104.1.11 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?DC01.Domäne.local:6002 400 1 Connection_Dropped DefaultAppPool

    Den lanmanserver parameter habe ich gesetzt und die Dienste entsprechend neu gestartet, Überprüfung läuft noch. 

    2012年4月2日 7:28
  • Hi,

    ist der Server virtualisiert? Wenn nein, ggf. Teaming aktiv? Ist das ein DC mit Exchange?

    VG, Timo

    2012年4月2日 22:06
    版主
  • Nachdem gestern Nachmittag die Anmeldung mit Outlook über RPC immer funktioniert hat, geht sie heute morgen wieder nicht mehr. Der lanmanserver parameter Eintrag brachte somit keinen Erfolg.

    Ja, er ist virtualisiert und ein DC mit Exchange.

    Gibt es vielleicht mit Outlook noch eine weitere Möglichkeit des Loggings? Schließlich tritt nur dort der Fehler auf.

    Es ist auch Officeversionsunabhängig, Fehler mit Outlook 2003/2010 reproduziert.

    Evtl. mal RPC Dienst und Outlook Anywhere deinstallieren und neu installieren?

    2012年4月3日 6:28
  • Hi,

    du schreibst das du Outlook über RPC angebunden hast, die Outlook Anywhere - Auth auf NTLm steht. Kann es sein das Outlook manuell für RPC konfiguriert ist und per Autodiscover den OA-Wert (die vorhandenen Outlook - Provider werder in Exchange mitgegeben) ausliest und versucht auf Outlook Anywhere umzustellen? Wird Outlook Anywhere denn benötigt? Wenn nicht kannst du es testweise mal ausschalten.

    Gib doch mal "Get-OutlookProvider" an der Shell ein bitte.


    Viele Grüße Walter Steinsdorfer MVP Exchange Server http://msmvps.com/blogs/wstein/ Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer"; if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. If a answer or remark helps you to cope with your problem you can "mark it as helpful".

    2012年4月3日 6:50
    版主
  • Outlook Anywhere ist doch nur ein anderer Name für http over RPC oder täusche ich mich da? Outlook wurde in meinen Tests manuell eingebunden und nicht via autodiscover. Outlook Anywhere muß doch im Exchange aktiviert sein damit ich überhaupt clients via https anbinden kann? Ich seh schon mir fehlt da wohl etwas Wissen.

    Hier der Auszug von Get-Outlookprovider:

    CertPrincipalName :
    Server            :
    TTL               : 1
    AdminDisplayName  :
    ExchangeVersion   : 0.1 (8.0.535.0)
    Name              : EXCH
    DistinguishedName : CN=EXCH,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=Firs
                        t Organization,CN=Microsoft Exchange,CN=Services,CN=Configu
                        ration,DC=Domäne,DC=local
    Identity          : EXCH
    Guid              : 7b446065-3373-43f5-9175-9558a3248956
    ObjectCategory    : Domäne.local/Configuration/Schema/ms-Exch-Auto-Discov
                        er-Config
    ObjectClass       : {top, msExchAutoDiscoverConfig}
    WhenChanged       : 20.05.2009 23:51:57
    WhenCreated       : 20.05.2009 23:51:57
    OriginatingServer : DC01.Domäne.local
    IsValid           : True

    CertPrincipalName :
    Server            :
    TTL               : 1
    AdminDisplayName  :
    ExchangeVersion   : 0.1 (8.0.535.0)
    Name              : EXPR
    DistinguishedName : CN=EXPR,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=Firs
                        t Organization,CN=Microsoft Exchange,CN=Services,CN=Configu
                        ration,DC=Domäne,DC=local
    Identity          : EXPR
    Guid              : 5532b172-ed99-4ceb-9f49-0feb38dc81be
    ObjectCategory    : Domäne.local/Configuration/Schema/ms-Exch-Auto-Discov
                        er-Config
    ObjectClass       : {top, msExchAutoDiscoverConfig}
    WhenChanged       : 20.05.2009 23:51:57
    WhenCreated       : 20.05.2009 23:51:57
    OriginatingServer : DC01.Domäne.local
    IsValid           : True

    CertPrincipalName :
    Server            :
    TTL               : 1
    AdminDisplayName  :
    ExchangeVersion   : 0.1 (8.0.535.0)
    Name              : WEB
    DistinguishedName : CN=WEB,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=First
                         Organization,CN=Microsoft Exchange,CN=Services,CN=Configur
                        ation,DC=Domäne,DC=local
    Identity          : WEB
    Guid              : 2ae850fd-cacf-4fef-88b3-17c2ab312b50
    ObjectCategory    : Domäne.local/Configuration/Schema/ms-Exch-Auto-Discov
                        er-Config
    ObjectClass       : {top, msExchAutoDiscoverConfig}
    WhenChanged       : 20.05.2009 23:51:57
    WhenCreated       : 20.05.2009 23:51:57
    OriginatingServer : DC01.Domäne.local
    IsValid           : True

    2012年4月4日 7:05
  • Hallo IT-Bändiger,

    ich muss nochmal zurück springen, vielleicht hab ichs auch überlesen / nicht richtig verstanden.

    Sind Deine Clients nun per Outlook Anywhere (=RPC over HTTPS) über Internet angebunden oder ganz normal TCP (RPC) intern im LAN ?

    Wann kommt es genau zu dem Problem aus dem Internet oder auch intern ?

    Wenn das Problem nur aus dem Internet auftritt, versuche direkt auf dem Exchange Server (CAS) folgendes:

    Rufe https://localhost/rpcproxy/rpcproxy.dll auf, kommt ein Fehler mit der Fehlernummer 600, funktioniert Dein Outlook Anywhere grundsätzlich.

    Wenn dann beim Versuch mit einem Client aus dem Internet wieder Login Boxen kommen überprüfe Deine Firewall-Konfiguration vor dem Exchange Server. Es kann sein dass durch Angriffserkennungsfeatures auf dem Firewall die Verbindungen unterbrochen werden. Ein Indiz dafür sind die Fehler in Deinem HTTP Error Log.


    Grüße, Christoph

    2012年4月4日 18:28
  • Hallo Christoph,
    es gibt keine Probleme wenn die Outlookclients mit TCP angebunden sind nur mit Outlook Anywhere kommt es zu diesem Problem. Das Problem tritt sporadisch auf nach dem man den Befehl iisreset /restart ausgeführt hat, manchmal nach 3 Std. manchmal aber auch erst nach 6 Std., ich konnte es zeitlich noch nicht eingrenzen.
    Gleich nach dem Restart funktioniert die Authentifizierung über Outlook Anywhere ohne Probleme via NTLM. Nach einer unbestimmten Zeit wenn man sich erneut anmelden will kommt einfach immer wieder das Authentifizierungsfenster obwohl die Benutzereingaben stimmen. Bei den bereits angemeldeten Benutzer bleibt die Verbindung aber erhalten.

    Wenn man einen Test mit dem Microsoft Remote Connectivity Analyser Outlook Anywhere mit Autoermittlung macht funktioniert alles einwandfrei (keinen Fehler).

     Auch wenn man die Outlookprotokollierung anschaltet und Autodiscover überprüft, keine Probleme.

    Wenn ich https://localhost/rpcproxy/rpcproxy.dll aufrufe auf dem EXCH-Server kommt: Serverfehler in der Anwendung "Default Web Sitte" HTTP-Fehler 404.0 - Not found https://localhost/rpc/rpcproxy.dll funktioniert

     Das gleiche wenn ich von Aussen komme. Die Firewall schließ ich mal aus, da andere Kundensystem hinter der gleichen Firewall keine derartigen Probleme haben, ich lasse es aber durch einen Kollegen überprüfen.

    2012年4月4日 19:40
  • Ich habe gerade getestet wie sich der Zugriff auf https://localhost/rpc/rpcproxy.dll bzw. https://mail.xxx.de/rpc/rpcproxy.dll verhält wenn das Problem besteht und nach einen IIS Restart:

    Wenn das Problem mit der Anmeldung besteht und ich mich mit dem benutzer direkt auf der RPC Webseite authentifiziere kommt eine Meldung mit dem Inhalt: Benutzer hat keine Berechtigung den Inhalt anzuzeigen (genauen Wortlaut kann ich erst später wiedergeben).

    Nach dem IIS Restart kommt einfach nur eine leere Webseite.

    2012年4月5日 10:18
  • Hallo IT-Bändiger,

    interessant ist, dass der Aufruf sowohl von innen als auch von aussen nicht klappt, das ist dann ein sicheres Zeichen, dass kein Firewall oder dergleichen schuld ist, sondern die RPC Komponente tatsächlich crasht.

    Es gab hier im englischen Forum mal einen ähnlichen Fall: http://social.technet.microsoft.com/Forums/en-US/exchangesvrmobility/thread/ab1b6897-e512-41f8-94c8-43e1d8fe9eba

    Meiner Meinung nach hast Du nur die Möglichkeit, Outlook Anywhere neu zu aktivieren und dabei den RPC-over-http-proxy in Windows Server 2008 einmal neu installieren.

    Ein Reihenfolge könnte so aussehen:

    -Outlook-Anywhere deaktivieren

    -RPC-over-http proxy Komponente über Powershell / Servermanager entfernen

    -Server rebooten

    -RPC-over-http proxy wieder installieren

    -Outlook Anywhere wieder einschalten

    Grundkonfiguration hier : http://technet.microsoft.com/en-us/library/bb123889(v=exchg.80).aspx

    Vorher sichern , dokumentieren versteht sich von selbst.

    Nachtrag:

    Ein Terminaldienste Gateway wurde nicht zufällig auf der Maschine installiert?


    Grüße, Christoph

    2012年4月5日 13:41
  • Leider kein Erfolg, gestern RPC Proxy und Outlook Anywhere deinstalliert/deaktiviert und wieder neuinstalliert/aktiviert (nach entsprechenden Neustarts), nach der Aktivierung war die Anmeldung erfolgreich, heute morgen war das Authentifizerungsproblem wieder vorhanden.

    Kein Terminaldienste Gatesway, das einzigste was so noch installiert ist, ist die KAV-Administrationskonsole und KAV für Windows Server.
    2012年4月10日 8:07
  • Hallo,

    zeigt das Eventlog am Server irgendwas Relevantes an?

    Hast du nach der Installation des SP3 auch das aktuelle RU6 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;2608656) installiert?

    Grüße,

    Toni

    2012年4月10日 9:32
  • Hallo,

    ich vermute mal, das der Kaspersky dir da in die Quere kommt.

    Die Exchange-Verzeichnisse sind richtig aus dem Online-Scan ausgeschlossen?

    Was sagt der Hersteller dazu?

    ;)


    Gruß Norbert

    2012年4月10日 12:03
  • Hi nochmal,

    wie Norbert schon schreibt deutet alles auf den Kaspersky hin.  Ich würde auch empfehlen den Hersteller hinzuzuziehen.

    Ich kenne einige Fälle wo nur noch die Deinstallation des Kaspersky weiter geholfen hat.

    Checke auf jeden Fall noch die Ausschlüsse: http://technet.microsoft.com/en-us/library/bb332342(v=exchg.80).aspx


    Grüße, Christoph

    2012年4月10日 14:38
  • Den KAV für Windows Server habe ich nun deinstalliert und auch das Removaltool laufen lassen, anschließend neu gestartet, leider kein Erfolg. Das ganze tritt auch richtig sporadisch auf, nach dem Server neustart ging die Anmeldung nach 10 Min. nicht mehr, nach einem IIS Restart lief die Anmeldung aber nun für 3 Std.

    Schön langsam bin ich soweit und mache einen Fall bei Microsoft auf.

    RU6 ist auch installiert.


    2012年4月11日 14:22
  • Hallo IT-Bändiger,

    nur um nochmal ganz sicher zu gehen! Du verbindest Dich ueber Outlook Anywhere (HTTPS), oder? Schau Dir bitte mal den Verbindungsstatus im Outlook an, da siehst Du welches Protokoll gerade genutzt wird. Idealerweise machst Du mal einen Screenshot davon und dann nochmal einen Screenshot wenn das Problem wieder auftritt. Vielleicht gibt uns das einen Hinweis, welche Verbindung dann authentifiziert werden moechte. Haben Deine Clients eigentlich einen Proxy eingetragen?

    Du hast anfangs mal geschrieben, dass auf dem Server auch ein DC laeuft. Ist der auch Global Catalog?

    Schmeisst der ExBPA irgendwelche Fehler oder Warnungen? (Seltsam, dass wir diese Frage in diesem Thread bisher noch nicht hatten :-)).

    VG, Timo

    2012年4月11日 20:09
    版主
  • Hi,

    das mit ExBPA wundert mich auch etwas. J

    Funktioniert OWA zu dem Zeitpunkt? Im EventLog gibt es keine weiteren Hinweise?

    Schau dir mal folgenden Link an und kannst du einen festen Zeitabstand zwischen den Problemen feststellen?
    http://technet.microsoft.com/en-us/library/dd421855(v=exchg.80).aspx

    Ansonsten wäre es wohl wichtig etwas tiefer ins IIS Troubleshooting zu gehen:
    http://mvolo.com/blogs/serverside/archive/2007/07/26/Troubleshoot-IIS7-errors-like-a-pro.aspx

    Irgendwo müssen Meldungen erzwungen werden, die etwas mehr zur Ursache und dem Problem verraten…

    Viele Grüße
    Christian

     

    2012年4月12日 6:12
    版主
  • - BPA Konnektivitätsprüfung (während das Problem besteht): kein Fehler
    - Remote Connectivity Analyzer ((während das Problem besteht): Fehler
    Die ersten Punkte sind erfolgreich, bei "Es wird versucht, ein Ping-Signal an RPC-Proxy mail.xxx.de zu senden." kommt es zu einem Fehler:
    An RPC-Proxy kann kein Ping.Signal gesendet werden.
    weitere Details:
    An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to long onto an Office 365 service, ensure you are using your full User Principal Name (UPN).
    - IE Aufruf der Seite https//mail.xxx.de/rpc (während das Problem besteht, egal ob Benutzer oder Administrator)
    > man muß dreimal auf Anmelden gehen, erst dann nimmt er die Authentifizierung an und bringt anschließend: Sie sind nicht berechtigt, dieses Verzeichnis oder diese Seite anzuzeigen.
    > das gleiche passiert auch wenn man (während das Problem besteht) sich auf dem Server via localhost auf der rpc Seite anmeldet (somit ist die Firewall wohl ausgeschlossen)
    - nach dem IISReset /restart funktioniert die Anmeldung auf https//mail.xxx.de/rpc sofort und es kommt nur eine leere Seite im IS
    - Das Problem tritt wie oben erwähnt nur sporadisch auf, manchmal nach 10 Min, manchmal aber auch erst nach ein paar Std.
    - OWA funktioniert (während das Problem besteht)
    - Wenn das Outlook über HTTPS verbunden ist, bleibt die Verbindung bestehen, auch wenn das Problem auftritt, erst wenn man Outlook neu startet und man sich wieder authentifizieren muß bemerkt man das Problem.
    - der DC ist auch GC

    Meiner Meinung nach stimmt etwas nicht mit dem IIS bzw. der RPC Seite, ich check jetzt nocheinmal die Ereignisprotokolle und schau mir den Link mit IIS Troubleshoot an.

    Danke für die bisherige Unterstützung.


    2012年4月12日 8:54
  • Fehler weiter eingeschränkt > es betrifft nur den DefaultAppPool im IIS (/RPC, /RPCWithCert, Stammanwendung), wenn man diesen stoppt und wieder startet funktioniert alles wieder normal, ich habe nun die Eigenschaften des pools mit einem anderen Server verglichen und nur einen Unterschied festgestellt:

    in den erweiterten Eigenschaften unter Wiederverwendung > Regelmäßiges Zeitintervall (Minunten), bei funktionierendem Server 1740, bei dem Problemserver 0

    in dem Artikel geht es um ähnliches http://technet.microsoft.com/de-de/library/dd421855%28v=exchg.80%29.aspx wobei hier Microsoft sagt das man einen eigenen Pool anlegen sollte und den Wert auf 0 setzen.

    Als Gegentest habe ich den Wert auf dem Problemserver auch auf 1740 gesetzt und teste es im Moment.

    Evtl. hilft es auch wenn ich einen eigenen Pool anlege für RPC.

    2012年4月12日 12:24
  • Den Wert im DefaultAppPool zurücksetzen auf 1740 brachte keinen Erfolg , auch die Erstellung eines eigenen Anwendnugspool für RPC änderte nichts an diesem Problem.

    In den Ereignisaneigeprotokollen gibt es keinen Hinweis wenn man sich versucht erfolglos einzuloggen, auch keine Fehler vom IIS.

    zuletzt folgendes umgesetzt (Kernel Mode), leider kein Erfolg:
    http://technet.microsoft.com/en-us/library/dd421847(v=exchg.80).aspx


    2012年4月12日 14:19
  • Hi nochmal,

    letzte Sache die ich noch im Kopf hatte:

    Gleiche mal die IIS Einstellugen des RPC-Verzeichnis mit den Standard-Einstellungen ab:

    http://blogs.technet.com/b/exchange/archive/2008/02/01/3404755.aspx

    Ich würde dann ein Ticket eröffnen.


    Grüße, Christoph

    2012年4月12日 15:45
  • Die Notlösung war die Umstellung auf Standardauthentifizierung bei Outlookanywhere, scheinbar hat nur NTLM das Problem.
    2012年4月26日 14:32
  • Danke für die Rückinfo,

    sehr interessant, das werd ich mal nachstellen um zu schauen ob sich das reproduzieren lässt .


    Grüße, Christoph

    2012年4月26日 16:05