none
Exchange2010 SP1 bei manchen Usern funktioniert Owa bei manchen nicht

    Question

  • Hallo zusammen,

    ich habe einen Exchange 2010 SP1 Server. Die AD Konten waren alle bereits vorhanden, sodass ich über die Exchange Management Konsole den Usern nur noch die Postfächer hinzugefügt habe. Jetzt habe ich das Problem, dass manche User sich per Owa anmelden können und manche nicht. Lege ich ein neues Konto an und hänge dann ein Postfach an funktioniert es. Erstelle ich einen neuen User über die EM Konsole funktioniert es auch. Hänge ich einem bereits bestehenden AD Konto ein Postfach an geht es mal und mal nicht.

    Das habe ich bereits gemacht:

    User Attribute verglichen - Keine Auffälligkeiten

    Bei Problem Usern das Postfach deaktiviert und wieder angehängt - Kein Erfolg

    Das Passwort der User zurückgesetzt - Kein Erfolg

     

    Stehe da echt vor einem Rätsel, da das Owa an sich ja funktioniert...

     

    Grüße und danke im Voraus

    Lennart

     

    Thursday, July 28, 2011 1:15 PM

Answers

  • Schau mal im AD Konto der betroffenen User nach, ob deren Anmeldung auf bestimmte Rechner oder Zeiten beschränkt ist. Wenn ja, nimm das mal raus....

     

    Grüsse

    Axel

     

    • Marked as answer by EDVStraut Friday, July 29, 2011 6:33 AM
    Friday, July 29, 2011 6:27 AM

All replies

  • Hallo Lennart,

    hast Du schon einmal geschaut ob die OWA-Funktionalität auch angeschaltet ist für den jeweiligen User ?

    In der Exchange Console auf den User in den Eigenschaften, bei Postfachfunktionen kann man OWA dediziert abschalten.

    Welche Fehlermeldung kommt denn beim Zugriff bei den Usern bei denen es nicht funktioniert ?

    Gruß,Christoph

    Thursday, July 28, 2011 1:19 PM
  • Hallo Lennart,

    was heißt denn "funktioniert nicht"?

    Kannst du ein bisschen genauer beschreiben was für Fehler auftreten bzw diese hier auch posten?


    Viele Grüße - Malte Schoch - www.msblog.eu
    Thursday, July 28, 2011 1:19 PM
  • Hallo Christoph,

    Danke für die schnelle Antwort.

    Ja das Feature ist aktiviert. Ich bekomme die Fehlermeldung, dass Benutzername oder Passwort falsch seien. Ein Tippfehler kann es nicht sein, da es bei einem Testuser und mit Passwort 123456qwert nicht funktioniert. War jetzt nur ein Beispiel

     

    Gruß

    Lennart

    Thursday, July 28, 2011 1:21 PM
  • Hallo Lennart,

    was heißt denn "funktioniert nicht"?

    Kannst du ein bisschen genauer beschreiben was für Fehler auftreten bzw diese hier auch posten?


    Viele Grüße - Malte Schoch - www.msblog.eu
    Der Login funktioniert bei manchen Usern nicht.
    Thursday, July 28, 2011 1:25 PM
  • Hallo Lennart,
    Der Login funktioniert bei manchen Usern nicht.

    Ok. Kannst du noch beschreiben, was für eine Domäne du hast. Kommen deine User noch aus der Windows 2000 Welt? Was passiert, wenn du im OWA auf Integrierte Authentifizierung stellst - Sprich das der angemeldetet Benutzer durchgereicht wird. Kann sich der User dann anmelden?

    Hast du bei der Anmeldung mal probiert, die Domäne vorweg zu schreiben?
    Sind im AD bei den Eigenschaften des Users unter Konto beide Benutzernamen + Domäne eingetragen?


    Viele Grüße - Malte Schoch - www.msblog.eu
    Thursday, July 28, 2011 1:39 PM
  • Hi Malte,

    ich hab eine Windows 2008 Domäne. Die Clients sind alle WinXP oder Win7. IE7-9 wurden getestet.

     

    >Was passiert, wenn du im OWA auf Integrierte Authentifizierung stellst - Sprich das der angemeldetet Benutzer durchgereicht wird. Kann sich der User dann anmelden?

    Wo stelle ich das genau ein? Wird der User auch durchgereicht wenn er lokal arbeitet, Sprich: An Orten wo keine Einwahl möglich ist (User ist im Export tätig)

     

    Ich habe bei der Owa anmeldung eingestellt, das die Domäne nicht eingegeben werden muss sondern nur der Username. Allerdings funktioniert es mit der Option "Domäne+Benutzername" auch nicht.

     

    >Sind im AD bei den Eigenschaften des Users unter Konto beide Benutzernamen + Domäne eingetragen?

    Ja sowohl bei Benutzeranmeldename als auch bei Benutzeranmeldename (Prä-Windows 2000)

     

     

    Thursday, July 28, 2011 1:46 PM
  • Hallo Lennart,
    Wird der User auch durchgereicht wenn er lokal arbeitet, Sprich: An Orten wo keine Einwahl möglich ist (User ist im Export tätig)

    Ich gehe mal davon aus, dass der User ein Notebook hat. Das heißt er kann sich ja zu Hause trotzden mit seinem Benutzernamen an der Domäne "anmelden". Wenn er jetzt eine VPN Verbindung zur Firma aufbauen würde, dann würde er auch hier durchgereicht werden.

    Oder hast du dein OWA nach außen veröffentlicht? Wenn ja, wie würde es veröffentlicht? Wenn du eine reine Portfreischaltung auf den Exchange gemacht hast, kannst du diese Einstellungen einmal zum testen ändern, müsstest diese danach aber wieder zurückdrehen.. Das würde sonst nicht mehr funktionieren..

    Wo stelle ich das genau ein?

    Gehe mal bitte in die Exchange Management Console unter Serverkonfiguration -> Clientzugriff -> Eigenschaften von OWA -> Authentifizierung.. Dort wählst du folgendes aus:
    Integrierte Windows Authentifizierung
    Standardauthentifizierung

    Das gleiche machst du dann noch bei Exchange-Systemsteuerung (rechts daneben).
    Danach musst du bitte deinen IIS neu starten.

     


    Viele Grüße - Malte Schoch - www.msblog.eu
    Thursday, July 28, 2011 1:55 PM
  • Malte du bist ein Genie!

    Seid dem ich die Integrierte Windows Authentifizierung aktiviert habe funktioniert es! Was sagt uns das jetzt genau?

    Muss ich das jetzt aktiviert lassen?

    Gruß

    Lennart

    Thursday, July 28, 2011 1:59 PM
  • Hallo Lennart,
    Muss ich das jetzt aktiviert lassen?


    Natürlich aber bitte beachte meine Erklärung von oben, falls du OWA ins Internet veröffentlicht hast:

    Zitat:
    -------------------

    Oder hast du dein OWA nach außen veröffentlicht? Wenn ja, wie würde es veröffentlicht? Wenn du eine reine Portfreischaltung auf den Exchange gemacht hast, kannst du diese Einstellungen einmal zum testen ändern, müsstest diese danach aber wieder zurückdrehen.. Das würde sonst nicht mehr funktionieren..

    -------------------

    Also die Frage nochmal: Hast du OWA ins Internet veröffentlicht und wenn ja wie? Wenn du es nicht veröffentlicht hast, ist alles gut :-)

    P.S.
    wenn das nun funktioniert, läuft bei der anderen Anmeldung was schief. Denn hier wird der angemeldetet User übergeben...


    Viele Grüße - Malte Schoch - www.msblog.eu

    Thursday, July 28, 2011 2:02 PM
  • Hi,

    ich habe den Port freigegeben, sodass die User auch aus einem Interne Caffe Owa nutzen können. Also kann ich es integriert nicht stehen lassen. Nur wie funktioniert es auch mit Benutzernamen und Passwort Eingabe?

    Ich habe mich ja nicht vertippt...

     

    Danke schonmal für deine Hilfe!

    Thursday, July 28, 2011 2:13 PM
  • Hallo Lennart,
    ich habe den Port freigegeben, sodass die User auch aus einem Interne Caffe Owa nutzen können.

    Ne dann musst du es leider zurückdrehen aber wir wissen nun zumindest schonmal, dass es klappt :-)

    Dann müssen wir den Fehler noch ein bisschen suchen :-)

    Kannst du mal die Ausgabe posten, damit wir sehen können, was du genau eingestellt hast:

    Get-OwaVirtualDirectory | fl BasicAuthentication,WindowsAuthentication,DigestAuthentication,FormsAuthentication,LiveIdAuthentication,DefaultDomain,internalurl,externalurl,logonformat


    Viele Grüße - Malte Schoch - www.msblog.eu
    Thursday, July 28, 2011 2:25 PM
  • BasicAuthentication   : True
    WindowsAuthentication : False
    DigestAuthentication  : False
    FormsAuthentication   : True
    LiveIdAuthentication  : False
    DefaultDomain         : test.local
    InternalUrl           : https://exch01.test.local/owa
    ExternalUrl           : https://webmail.....com/owa
    LogonFormat           : UserName
    Friday, July 29, 2011 4:56 AM
  • Hi Lennart,

    würde es direkt am Exchange liegen, müsste es nach dem Alles-oder-Nichts-Prinzip funktionieren oder eben nicht.

    Würde es nicht funktionieren, würde ich die Vorraussetzungen nochmal prüfen und die Seite ggf. zurücksetzen:

    Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy

    Remove -OwaVirtualDirectory -Identity 'Server01\owa (Default Web Site)'

    New-OwaVirtualDirectory -InternalUrl 'https://<Server01><DomainName>/owa' -WebSiteName 'Default Web Site'

    siehe:

    http://technet.microsoft.com/de-de/library/ff629372.aspx#Shell

    Du kannst auch eine zweite OWA-Seite erstellen und damit testen...

    Ich würde mir mal die AD-Rechte einmal genauer anschauen - wurde die Vererbung eventuell deaktiviert? Vergleich mal die Objekte, wo gibt es Unterschiede?

    http://www.msxfaq.de/konzepte/adminsdholder.htm

    Viele Grüße

    Christian

    Friday, July 29, 2011 5:42 AM
    Moderator
  • Hi Christian,

    also funktionieren tut es ja...Nur halt mit ein paar Usern nicht.

    Ich habe die User Attribute bereits nebeneinander gehalten und nix finden können. Der Login bei Usern wo es nicht funktioniert, funktionierte ja nach dem Tipp von Malte als ich die Integrierte Windows Authentifizierung bei Owa aktiviert habe.

    Was meinst du genau mit AD-Rechten? es sind alles AD User mit standard User Rechten. Kein Admin Recht oder so.

    Vererbung ist aktiviert bei den ACLs

     

    Gruß

    Lennart


    Friday, July 29, 2011 5:50 AM
  • Schau dir mal Franks Link an, da wird gut beschrieben, was ich mit den Rechten mein.

    Erhöh auch mal das DiagnosticLogging und schau ins IIS-Log, was da genau als Meldung zurück kommt.

    Gibt es Fehler im EventLog?

    Die Voraussetzungen kannst du ja trotzdem mal Prüfen und eine zusätzliche Seite anlegen...

    Grüße
    Christain

    Friday, July 29, 2011 5:54 AM
    Moderator
  • Hi,

    sorry aber ich bin hier neu und weiß nicht wer Frank ist und auch nicht wo seine Links gepostet sind.

    Im IIS Log ist nix an Fehlern zu sehen. Der BPA gibt 2 Fehler für den IIS aus:

    • Fehler: Für Anwendungspool sollte festgelegt werden, dass sie als Anwendungspoolidentitäten ausgeführt werden
    • Fehler: Bei Standardauthentifizierung SSL verwenden

    Was mir im Sicherheits Log aufgefallen ist (Windows-Protokolle->Sicherheit) ist folgendes:

    • Protokollname: Security
      Quelle:        Microsoft-Windows-Security-Auditing
      Datum:         29.07.2011 07:43:20
      Ereignis-ID:   4625
      Aufgabenkategorie:Anmelden
      Ebene:         Informationen
      Schlüsselwörter:Überwachung gescheitert
      Benutzer:      Nicht zutreffend
      Computer:      Exch01.test.local
      Beschreibung:
      Fehler beim Anmelden eines Kontos.

      Antragsteller:
          Sicherheits-ID:        SYSTEM
          Kontoname:        EXCH01$
          Kontodomäne:        TEST
          Anmelde-ID:        0x3e7

      Anmeldetyp:            8

      Konto, für das die Anmeldung fehlgeschlagen ist:
          Sicherheits-ID:        NULL SID
          Kontoname:        Testuser
          Kontodomäne:        TEST.local

      Fehlerinformationen:
          Fehlerursache:        Der Benutzer ist nicht berechtigt, sich an diesem Computer anzumelden.
          Status:            0xc000006e
          Unterstatus::        0xc0000070

      Prozessinformationen:
          Aufrufprozess-ID:    0x764
          Aufrufprozessname:    C:\Windows\System32\inetsrv\w3wp.exe

      Netzwerkinformationen:
          Arbeitsstationsname:    EXCH01
          Quellnetzwerkadresse:    192.168.***.***
          Quellport:        50240

      Detaillierte Authentifizierungsinformationen:
          Anmeldeprozess:        Advapi 
          Authentifizierungspaket:    Negotiate
          Übertragene Dienste:    -
          Paketname (nur NTLM):    -
          Schlüssellänge:        0

      Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.

      Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".

      Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).

      Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde.

      Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an.  Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.

      Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
          - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
          - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
          - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.
      Ereignis-XML:
      <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
        <System>
          <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
          <EventID>4625</EventID>
          <Version>0</Version>
          <Level>0</Level>
          <Task>12544</Task>
          <Opcode>0</Opcode>
          <Keywords>0x8010000000000000</Keywords>
          <TimeCreated SystemTime="2011-07-29T05:43:20.743539600Z" />
          <EventRecordID>152734</EventRecordID>
          <Correlation />
          <Execution ProcessID="520" ThreadID="6736" />
          <Channel>Security</Channel>
          <Computer>EXCH01.test.local</Computer>
          <Security />
        </System>
        <EventData>
          <Data Name="SubjectUserSid">S-1-5-18</Data>
          <Data Name="SubjectUserName">EXCH01$</Data>
          <Data Name="SubjectDomainName">TEST</Data>
          <Data Name="SubjectLogonId">0x3e7</Data>
          <Data Name="TargetUserSid">S-1-0-0</Data>
          <Data Name="TargetUserName">testuser</Data>
          <Data Name="TargetDomainName">TEST.local</Data>
          <Data Name="Status">0xc000006e</Data>
          <Data Name="FailureReason">%%2312</Data>
          <Data Name="SubStatus">0xc0000070</Data>
          <Data Name="LogonType">8</Data>
          <Data Name="LogonProcessName">Advapi  </Data>
          <Data Name="AuthenticationPackageName">Negotiate</Data>
          <Data Name="WorkstationName">TEST</Data>
          <Data Name="TransmittedServices">-</Data>
          <Data Name="LmPackageName">-</Data>
          <Data Name="KeyLength">0</Data>
          <Data Name="ProcessId">0x764</Data>
          <Data Name="ProcessName">C:\Windows\System32\inetsrv\w3wp.exe</Data>
          <Data Name="IpAddress">192.168.***.***</Data>
          <Data Name="IpPort">50240</Data>
        </EventData>
      </Event>

    Friday, July 29, 2011 6:06 AM
  • Schau mal im AD Konto der betroffenen User nach, ob deren Anmeldung auf bestimmte Rechner oder Zeiten beschränkt ist. Wenn ja, nimm das mal raus....

     

    Grüsse

    Axel

     

    • Marked as answer by EDVStraut Friday, July 29, 2011 6:33 AM
    Friday, July 29, 2011 6:27 AM
  • Hi Axel,

    das war es! Du hast mein Problem gelöst!!! Vielen vielen Dank!

     

    Gruß

    Lennart

    Friday, July 29, 2011 6:32 AM
  • Chapeau! ...mit der Beschreibung hätte ich da als letztes geschaut und es hätte bei der Prüfung des AD-Objektes auffallen müssen...warum klappte die WindowsAuth? War wohl zufall mit den Zeiten?

    Viele Grüße

    Christian

    Friday, July 29, 2011 6:37 AM
    Moderator
  • Gern geschehen - hatte mal das gleiche Problem und hatte mir auch den Wolf gesucht...

    :-)

     

    Friday, July 29, 2011 6:37 AM
  • Hallo zusammen :-)

    haha wie geil ist das denn :-)

     

    Welcome Back Christian :-)


    Viele Grüße - Malte Schoch - www.msblog.eu
    Friday, July 29, 2011 6:38 AM
  • >> Welcome Back Christian :-)

    Ist das aufgefallen? :-) Zwei Wochen Urlaub und eine Woche ohne komplett ohne Notebook ist was tolles und jedem zu empfehlen! ;-)

    Viele Grüße

    Christian

    Friday, July 29, 2011 6:40 AM
    Moderator
  • Ist das aufgefallen? :-) Zwei Wochen Urlaub und eine Woche ohne komplett ohne Notebook ist was tolles und jedem zu empfehlen! ;-)

    Klar du bist ja sonst immer da :-) In einem Monat ist es bei mir auch endlich soweit:-)

    Viele Grüße - Malte Schoch - www.msblog.eu
    Friday, July 29, 2011 6:43 AM
  • Ist das aufgefallen? :-) Zwei Wochen Urlaub und eine Woche ohne komplett ohne Notebook ist was tolles und jedem zu empfehlen! ;-)

    aber hallo ist das aufgefallen :) sagte die Tage schon zu Malte : " Der ist bestimmt in Urlaub :)"

    Welcome back Christian !

    Friday, July 29, 2011 11:45 AM
  • Hallo.

     

    Versuche mal bitte:

    username@domain als User

     

    Diese Variante hat bei mir zum Erfolg geführt.

     

    Grüße

    Martin

    Thursday, August 18, 2011 11:29 AM